Experiments with user auth/db access #811
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
html select boxes to choose region/bundle/feed update map style JSON to match GTFS vector tile layer names try serving up vector tiles UI html/js without CORS
will eventually require token expiration/eviction
also url-safe tokens (can be included as a query param) factor out logic from streaming / non-streaming database endpoints added login and token example to vector tile client
abyrd
force-pushed
the
auth-db-experiments
branch
from
c4e28e3
to
7d31889
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is just to keep track of / allow attaching documentation to a branch I created a few weeks back to experiment with moving some user management into our own database tables, seeing how simple authentication could be for our use case, and testing this out with some very general purpose authenticated database access endpoints. Obviously all of this would have to be done over HTTPS not HTTP, some things should be in headers or request bodies rather than query parameters, etc. but it does seem to represent a viable approach.
I wouldn't really want to use a Java keystore to set up HTTPS - at this point we'd prefer to work with more common files and have identified some code/libraries to do this programmatically. But the Spark framework HTTPS setup doesn't seem to allow supplying a programmatically constructed keystore instance, only a filename for one on disk. So doing this whole thing cleanly implies migrating the HTTP API over to run directly on Jetty, or on something like Undertow, rather than Spark (which we've long been considering removing).