Closed alukach closed 3 weeks ago
@vincentsarago did a bit of a refactor, it's feeling a bit cleaner.
Going to try to put together some tests before marking this as ready.
I realize these are examples for sake of examples at this point. Looks good 🥳
I'm wondering if there is any future plans at all to promote a more reusable pattern. Something like an extension/plugin + enabled/disabled flag (similar to what exists here) for each service instead of forcing downstream users to copy pasta all this configuration for each service? Potentially other patterns to think about there too.
Certain projects such as EOEPCA+ have goals to actively avoid building custom runtimes b/c then it requires someone to manage the drift in future upgrades (@j08lue can comment if I'm off base there). There are other alternatives rather than this pattern for EOEPCA+ to use in that case (something like a policy enforcement service + nginx auth proxy in from of all eoAPI services). More about that later
I think it would be fine to create a eoapi.auth
submodule to store all the auth
related code which will then be a dependency to the eoapi.raster|vector|stac
submodule. I'm happy to start a PR on top of yours if you want @alukach
@vincentsarago yeah, I think that sounds reasonable. Are you thinking about an external repo to manage that?
@alukach for now we can have this here I think
@vincentsarago Sounds good, if you’ve got it in you, please do break out the auth into a separate module. I had considered doing this but didn’t immediately have any good strategy for copying the module into each docker service or using it as a dependency. Curious to see what you have in mind.
What I am changing
-
How I did it
-
How you can test it
-
Related Issues
-