Closed DeflateAwning closed 9 months ago
Dear @DeflateAwning
We appreciate the contribution.
Adding Auth on top of titiler application should be done at user level. We see titiler.application
module as a demo not as something that should get used in production and specifically if users required auth.
Global access token
is pretty weak auth and I don't think it provide real security (IMO) which is why in the documentation we added https://developmentseed.org/titiler/examples/code/tiler_with_auth/ to show how users can implement auth on their own application.
I agree that's it's not cut out for every use case, but I maintain that it's a good method method, in cases where the authentication is handled through another system. Managing two authorization tools when TiTiler is being proxied through another API with authentication is ineffective.
@DeflateAwning can you resolve the issue to make sure the code works with python 3.8 🙏
Done! Forgot about that old Python3.8/3.9 type hinting syntax
@DeflateAwning can you run pre-commit 🙏
Hmm, I ran all the content in CONTRIBUTING.md before the Docs section, and then ran pre-commit
, but there are no changes detected (on the latest version of this code). Is there something I'm missing? Was in Python3.11 venv.
Fixed. I changed 403 to 401 everywhere applicable (including docs).
This PR is a feature addition, which allows the addition of a global access token to all endpoints.
This feature is important because it allows implementing a basic security, in cases where the endpoint is routed through a machine-to-machine connection. For example, a Ruby API handles all incoming requests and performs the user permissions validation, and then proxies the requests onto a TiTiler server; no requests from outside the Ruby API should be allowed to access the TiTiler endpoints directly.
Please advise if any changed are required for acceptance of this small feature addition!