-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix DEV stack authentication url with localhost redirect_uri #743
base: main
Are you sure you want to change the base?
Conversation
I tried testing this. What I observed was:
Is that expected? In Slack you mentioned that there's a backend issue that affects this too, so maybe that's what I'm seeing, but just wanted to check. |
@jake-low I think this solution will not work. I'm seeing this error in the osmcha backend when I try to login: |
Hmm .. can we try:
Another thing to try is maybe redirecting to http://localhost:8000 instead of http://127.0.0.1:8000 here: https://github.com/OSMCha/osmcha-frontend/pull/743/files - this redirect is basically being performed by Am pretty certain this should be the issue - if 127.0.0.1 already exists in the list of allowed Redirect URIs, then I don't know what's going on ... |
@batpad I have A solution I used on another project was to add another endpoint in the backend to authenticate and redirect the user to 127.0.0.1 |
I was looking into this a bit yesterday. I think I understand the problem with this approach now, though I still need to think a bit more about how to solve it. The
When requesting an access token, the backend must provide the authorization code to the OAuth provider (openstreetmap.org). But it must also provide the redirect URI, and it is an error if this redirect URI doesn't match what the frontend used when it generated the code (see RFC 6749 Section 4.1.3 for the specifics). The frontend has tampered with the URL that the backend provided it, but the backend doesn't know this. By itself, this tampering is fine (anyone can generate these URLs; you don't need to know the application secret). The authorization flow succeeds, at least from the perspective of openstreetmap.org, and a valid authorization code is sent back to the frontend via redirect. But the backend doesn't know the correct redirect URI required to use this code. When it tries to use the code with the incorrect redirect URI to fetch an access token, openstreetmap.org returns an error. The solution to this is to have the backend somehow know the correct redirect URI to use for a code, which on its own isn't too hard. For example, instead of using a fixed value from an environment variable, it could use the value of the However, the Another possibility would be to forego the For convenience, here is the full stack track of the error from the backend. I have no idea why the message at the end is in Czech. It translates to "The authorization grant provided is invalid, expired, revoked, does not match the redirect URI used in the authorization request, or was issued to another client".
|
@jake-low feel free to try the solution you proposed, although I think this issue is not a high priority right now. |
No description provided.