Principled code generation from OpenAPI specifications. https://guardrail.dev/
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?
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
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.
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 š
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 š
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
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?
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.
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
ok, so it's just more convenience thing that this is missing. That should be ok for my use case šļø
Yes. Low level protocol work can be done by way of supplying a pre-authenticated
HttpClient[F], by way of FooClient.httpClient[F[_]](httpClient: Http4sClient[F], host: String = "http://localhost:1234")(implicit F: Async[F]): FooClient[F]
this is also used in the case of servers that misrepresent content types or include other odd network features that must be coerced
had a look at my generated client and was wondering exactly that š
Of course! I'm going to keep driving now, but please enjoy your evening
I wanted to ask a question about optional fields on objects, is it possible to disable the
= None default values for optional values?
@lolgab Pardon for the delay in response! I must have missed the notification.
This isn't currently configurable, though I'm curious about your use case. Would you want to disable this in all cases, in order to make it obvious where the code needs to change if a spec changes?
The location where those None values are interpolated is here
I don't have a great answer for you right now, since I'm still working on guardrail-dev/guardrail#1414, but once that is merged and released, you should be able to define a subclass of any of these generators directly in sbt, for instance like
project/src/main/scala/dev/guardrail/CirceOverrides.scala. I'm trying to get that wrapped up soon, life has been getting in the way a bit š
Would you want to disable this in all cases, in order to make it obvious where the code needs to change if a spec changes?
Yes, I try to avoid default parameters since I always forget to propagate some of them and end up creating bugs.
I check if I can define that override myself, thank you very much :)
I'll really try to wrap up the
spi branch in the next few weeks, if you don't mind waiting; I can provide a working example of what you're trying to do once it's done
This kind of extensibility is a desired feature, to support companies that need to add internal frameworks
Hey all, I'm wondering what the status is of the projects CI -- github runners are failing, and have been for a long time. Can I help getting that passing?
martijn.hoekstra.zivver: It's an unfortunate state of the MiMa checker -- I'm changing how the module system works, building towards a new minor release, but the build fails unless there's the GitHub major or minor tag present in the build event...
I was thinking of trying to use the GitHub API to collect the semver tags of merged PRs, though maybe as a stopgap just disabling MiMa checking on master would be acceptable
@martijnhoekstra: Thanks for bringing this up -- it was easy to lose sight of the visibility of the master CI tests and what that means to people checking out the repo for the first time. I've fixed it now, hopefully that improves confidence more broadly.
or martijn.hoekstra.zivver... sorry, mistyped
Stale PRs now reduced to 14 -- getting closer to addressing them all š
@lolgab: OK. It's a little messy, but it is now possible to override built-in functionality in the source generators.
https://gist.github.com/blast-hardcheese/4e0037332eb606330b90c3b19650e874 is a gist to explain how to do it, with a link to a branch in the
https://gist.github.com/blast-hardcheese/4e0037332eb606330b90c3b19650e874 is a gist to explain how to do it, with a link to a branch in the
sample-sbt-http4s repo where it is used.
The reason I think this is useful is it permits new feature development, alternately better fitment to custom internal idioms.