Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 00:30
    blast-hardcheese commented #1530
  • 00:10
    MarErm27 commented #1530
  • Jul 06 23:42
    MarErm27 commented #1530
  • Jul 06 23:16
    MarErm27 opened #1530
  • Jul 06 17:52
    stanislav-chetvertkov synchronize #1510
  • Jul 06 17:31
    stanislav-chetvertkov synchronize #1510
  • Jul 06 17:29
    stanislav-chetvertkov synchronize #1510
  • Jul 06 03:32
    github-actions[bot] labeled #1514
  • Jul 06 03:32
    github-actions[bot] labeled #1514
  • Jul 06 03:32
    github-actions[bot] labeled #1515
  • Jul 06 03:32
    github-actions[bot] labeled #1516
  • Jul 06 03:32
    github-actions[bot] labeled #1511
  • Jul 06 03:32
    github-actions[bot] labeled #1512
  • Jul 06 03:32
    github-actions[bot] labeled #1517
  • Jul 06 03:32
    github-actions[bot] labeled #1513
  • Jul 06 03:32
    github-actions[bot] labeled #1514
  • Jul 06 03:32
    github-actions[bot] labeled #1518
  • Jul 06 03:32
    github-actions[bot] labeled #1518
  • Jul 06 03:32
    github-actions[bot] labeled #1515
  • Jul 06 03:32
    github-actions[bot] labeled #1516
Ondra Pelech
@sideeffffect
Good to know! Thanks
Stanislav Chetvertkov
@stanislav-chetvertkov

Hi, is there a simple fix for cases where the protocol field names contain reserved words? for example

  schemas:
    MacroWrapper:
      type: object
      required:
        - macro
      properties:
        macro:
          $ref: "#/components/schemas/ZendeskMacro"

gives macro is now a reserved word; usage as an identifier is disallowed, I don't want to use the x-jvm-typeor x-scala-type extensions as a workaround because it would introduce unnecessary complexity.
If there is no fix for this yet (I'm on version 0.64) I could create an issue and for on a fix

blast_hardcheese
@blast_hardcheese:matrix.org
[m]
@stanislav-chetvertkov: I believe guardrail-dev/guardrail#438
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Actually, more importantly, scalameta/scalameta@ca0de48 which will have been merged in a scalameta upgrade in guardrail, will cause macro to be surrounded in backticks, like other reserved words
so if you can upgrade to a newer version of guardrail internally, that would be preferable.
Additionally, the new repository modularization work will mean that providing modules for Twilio-internal generators (scala-service, twilio-scala-dropwizard) will vastly reduce the amount of code that will need to be maintained. That being said, as much as I have tried to avoid using SPI, I think it would be preferable to use an SPI mapping for guardrail modules, otherwise you are relying on library eviction or pinning
Stanislav Chetvertkov
@stanislav-chetvertkov
Thanks Devon, I'm currently trying to restructure the twilio guardrail repo - it hasn't been updated since 0.64 and its quite a lot of work but we are getting there
3 replies
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
One thing I've been considering is removing the tracing boolean, as it is better served by way of composition now that mapRoutes exists in a number of frameworks. I would like to do this in a way that doesn't break Twilio, so if you know people are still using that feature directly, I can come up with a migration strategy.
1 reply
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
(it was possible before, though would have been more difficult due to the dependency chain)
kelnos
@kelnos:matrix.org
[m]
yeah, i suggested that we should kill the submodule and start depending on the built artifacts. i'm just afraid that anything else will be a difficult maintenance burden later. unfortunately i haven't had the time to look at it myself
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Yeah, that's what I had in mind as well. Good to see we're on the same page
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
kelnos Do you have any recollection of this? Looks like a simple typo in an uncommon framework (scala-dropwizard): https://github.com/guardrail-dev/guardrail/pull/1331/files#diff-038ddff44db3d6599f6eaec4bece42fb97081152ff3e7eebfe554a385260a07dR96-R168
I'm trying to resolve the mass of warnings from the OpenAPI parser due to sloppy regression specifications
found that one when fixing where default was specified
kelnos
@kelnos:matrix.org
[m]
yeah that does seem to be a typo. i'm surprised the same typo isn't present in the java-DW thing tho
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
so interestingly, I don't think we emit defaults in the same way for java-dropwizard
kelnos
@kelnos:matrix.org
[m]
odd
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
when I fixed the spec, only the scala code was altered
kelnos
@kelnos:matrix.org
[m]
huh, ok
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
yeah. Presumably this'll shake out as I move forward with guardrail-dev/guardrail#1359
I think despite getting to the "right" solution, I got there the wrong way, so I'm gonna take another crack at it
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
This is getting quite good, actually: guardrail-dev/guardrail#1342
excited to merge that
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Recording from the talk at CASE Meetup a few weeks ago: https://youtu.be/GUwkjCX1Xu0
jonasberg
@jonasberg:matrix.org
[m]
blast_hardcheese I would like to use the basic auth for http4s feature introduced in guardrail 0.70.0. I added a basic-auth scheme in the securitySchemes component and referenced it globally in the security section of my openapi config. However guardrail still generates the same Handler as before. I'm using the sbt plugin for the generation. Is basic auth support only available in the cli app or am I missing something?
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
jonasbergI I don't remember the field being added to the SBT plugin; I may be incorrect, but I believe that is required in order to get the new functionality.
guardrail-dev/sbt-guardrail#171 does the same thing for the coding and tags handler options, exposing a new set of keys and a new parameter for the auth style will need to be added. It didn't even occur to me when I was working in there yesterday, I've been trying to finalize this modularization work
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
jonasberg: if you don't have time (or haven't started) I'm just getting to a rest stop now, I can do another release real quick
jonasberg
@jonasberg:matrix.org
[m]
Ah I see. I was reading that issue that requested the basic auth support for http4s and in there, there was an instruction how to generate a Server with auth by CLI. That's why I figured maybe this feature hasn't made it to the sbt plugin yet.
Sure, I can (try) to take care of that. I won't be able to do it today as it is already late but if there is no hurry I'm going to implement it and create a PR.
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
Yep -- the functionality is in the core and CLI drivers, but you're exactly right -- it didn't get all the way to the sbt plugin
I'll take care of it now and have a new release, 0.70.0.2, with that functionality shortly. It's my fault for not noticing that it wasn't finished in the first place 😉
jonasberg
@jonasberg:matrix.org
[m]
ok ok :)
I just started using guardrail and was not in touch with its internals
so if you want to push 0.70.0.2 soon, I agree it might be better if you do it this time 😁
ah hey: thank you for adding basic auth support 🙏
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
almost entirely community driven, I'm appreciative for the contribution as well 🙂
the guardrail internals are not particularly straightforward, but things are getting better I think
guardrail-dev/sbt-guardrail#172 is available for review, I'll leave it up for a few hours then merge and release
jonasberg
@jonasberg:matrix.org
[m]
awesome, thank you 👍️
I haven't had a deep look into the Code of your basic auth PR, but am I right that for the server-side the specified auth type doesn't really matter, because you provide your own logic through the http4s middleware. Where it makes a difference is on the client side. Is that correct?
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
jonasberg Correct. There are a few different variants of the server auth generator that all transform the Routes into AuthedRoutes parameterized by whatever type you specify
Even though the initial PR was intending to only support basic auth, by the end we ended up conforming to http4s' auth middleware interface, so it is actually compatible with digest auth, oauth, and other middleware providers
hopefully this isn't a problem for you, but http4s client generation has not been altered to support the different authentication schemes yet.
presumably it would be straightforward to add now that the groundwork is done, if that's necessary, I've just had my head down on this modularization work.
jonasberg
@jonasberg:matrix.org
[m]
If you generate a client based on a api spec that has auth for all or certain endpoints, is there a way to add credentials to the generated client today?
or is that not possible at all
blast_hardcheese
@blast_hardcheese:matrix.org
[m]
that's certainly possible.
jonasberg
@jonasberg:matrix.org
[m]
ok, so it's just more convenience thing that this is missing. That should be ok for my use case 👍️