-
Notifications
You must be signed in to change notification settings - Fork 78
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
Deprecation of HTTP Basic Auth and OAuth 1.0a #286
Comments
Thanks for the notice. I'm looking into this with a higher priority. There is OAuth2 library in Qt. However, reading osm docs it appears I need to generate client_id and secret. However, I can't keep the secret secret. I looked briefly into josm and could not find a secret in the source code, not sure if they just inject it at buildtime though. Do you have any visibility into the preferred way to do it? |
Ah, this was briefly discussed today in the IRC chat
I'm going to add a brief mention in that wiki article; feel free to link other OSM docs where you think it should be mentioned. |
Thanks, that's helpful. I got it working. However, I'm not sure how to check if it's doing what it's supposed to do.
I would expect the OSM server should require at least one of these things to be present? Anyway, it looks like I can successfully use the OAuth2 flow with OSM API, so I'll integrate it with the rest of the system. The only big downside I see now is I seem to require a separate client id for every server (main/test api/3rd party servers). |
When I was adding support for OAuth 2 in JOSM, I implemented a bunch of "optional" stuff that is likely to become mandatory with OAuth 2.1 and didn't implement some things that were optional in OAuth 2.0 but were removed/deprecated in the OAuth 2.1 draft. If you are writing your own OAuth lib instead of using someone else's, I would highly recommend implementing PKCE. But you should probably use someone else's OAuth library. I don't know how you are intending to implement the OAuth redirect, but in JOSM I'm using the remote control endpoint
Yep. That is a downside. I'm currently only planning on hardcoding the main api and test api oauth client ids in JOSM. There is an RFC for dynamic client registration, but it isn't currently implemented in the library the OSM website is using. EDIT: The OSM website now implements the RFC for getting OAuth endpoints, see https://www.openstreetmap.org/.well-known/oauth-authorization-server . |
Basic Auth and OAuth 1.0a have been turned off on July 1st now. Merkaartor upload to osm is currently not working anymore. |
Have it been commit to any branch or repo? Can you share that code? |
Work in progress on my personal branch. I have some local stuff not there yet. I've got the auth working + the UI, but need to put that together. |
Well, I pushed the recent version. The refactor is mostly OK, download works. But it seems since last time I tested the flow, something changed and my Qt oauth component sends redirect url as http://localhost:1337/ instead of http://127.0.0.1:1337/. Unfortunately, I can not set localhost on the osm.org website, due to non-IP redirect addresses needing https. I'll continue tomorrow, but you can test if it works for you. One caveat is it will NOT work against other APIs than main osm.org due to hardcoded client_id. I will at least add client id for the testing API tomorrow. |
Ok, so the IP is fixed, well, hacked. However, now I'm stuck getting the actual bearer token, and the QT handler eats the error (it likely is in the body, which it ignores).
|
Just pushed to the branch (https://github.com/Krakonos/merkaartor/commits/oauth2 ) with basic functionality. What works:
What does not work:
If you've got time, I'd appreciate some rough testing. So far it works for me (tm). |
I now cannot upload data anymore. When I upload, I get the error message
So Merkaartor seems no longer usable right now, making this an important/ deal breaking issue. (I use latest release 0.19.0 from my distribution. If you have already fixes for this, maybe do a new release?) |
If you can, please test the branch marked above. I'm busy over the week, but I think I'll merge & release it over the weekend. |
I'm busy over the
week, but I think I'll merge & release it over the weekend.
OK, great!, so I will just wait until my distribution picks up.
|
Sorry for delay... I managed building the code. But not from the first attempt. What have I done:
Same story I get when I build it master branch. I looked at the make file with error, found protobuf mentioned there, and tried to configure with This helped. So I built it and run it. I tried to login via oauth2 method, but failed: I am using KDE on this computer, Then I pressed "Login button" it opened knqueror browser (I never changed browser defaults here), then konqueror automatically reopend that page in firefox (I do not know why, it changed to that behavior after one update, I've never configured it). This page has URL "https://www.openstreetmap.org/api/oauth2/authorize?client_id=wv3ui28EyHjH0c4C1Wuz6_I-o47ithPAOt7Qt1ov9Ps&code_challenge=k-8NhjKbEjfP_hPtscyFkRO_ZmUghWjySZhDkyupp5E&code_challenge_method=S256&redirect_uri=http://127.0.0.1:1337/&response_type=code&scope=read_prefs%20write_prefs%20write_api%20read_gpx%20write_gpx%20write_notes&state=BNF39NRK" and it said, if I translate it back from Russian:
In the console Merkaartor wrote following lines:
I do not know how does this OAuth2 communicate with the browser, but I whould suspect, that this issue with redirecting might break everythig. As far as I know Qt has some limited html-rendering engine that can be used to handle that OAuth2 stuff. Guess better not try to rely on OS browser facility, as it is not reliable, and use browser of our own, if it is ever possible. |
Tried to do the same thing on laplop with LXQt:
My idea is still the same: external browser is not reliable... |
I think I'm able to reproduce your issue. The URL entered has to be Notice that http changes to https, and the /api/0.6 goes away. After these modifications, it seems to work with redirects. I could embed a browser window instead, but that window is not necessarily trusted, and some features might be missing - as one example, users tend to have password managers that are not usable in this scenario. Also, there might be a second flow necessary that doesn't use redirect, which could be problematic, but a code shown in browser instead. In this instance, we can also show the login URL user needs to navigate to. This can be then done on a different computer even, so I think that is a feasible backup solution. Edit: The second issue seems you have empty URL field, can you check the contents there? |
Adding https://www.openstreetmap.org/ to the URL solves that problem on both laptops.... Both successfully opens login dialogs I would suggest to change that dialog to the radio button choice: First is fixed " https://www.openstreetmap.org/" second is a field for custom URL. 98% of users will need the first choice. But whenever I properly enter login, password and confirm that I trust merkaartor app, I am redirected to http://127.0.0.1:1337/?code=XXXXXXXXXXXXX page, that reports that connection can not be established. telnet does not want to connect that address/port too May be if we use built in browser, there will be no need in built in server to response on 127.0.0.1:1337, so we just grab that code from the redirect http request without processing it? :-) |
Hm... This I did not think about...
As for me, I would not trust any external browser app. But that is my preferences :-)
This sounds as a good idea... Much better then running local web server :-) |
Yeah, the port is a problem due to how the Qt library handles the thing. I will implement the manual flow as a backup and release the port flow as is and try to figure out how to improve it. There are other issues with it - mainly the osm.org site returns errors in response body, but the flow does not give me API to retrieve that body in the error handler. I'm not sure if this can be fixed by inheritance, but TBH at that point it might be easier to roll a custom "library", since the OAuth2 flow in Qt requires so much boilerplate around it, it doesn't really give us much... |
If you get stuck with it, please let me know. I do not have much time, and I have not beet working with Qt for more than 15 years, so it would not be easy for me, but this issue should be fixed... |
Well, I pushed a few UI changes with a slightly better error reporting and better messaging. |
Should I test anything? |
You can have a look at the UI, but functionality should be mostly unchanged (except for some error handling, which is still sub-par due to deficiencies in the qt library). I'll find some time today to work on the manual (OOB) flow. |
OOB flow pushed. You can give it a go. I have it set up so it opens the URL automatically, the dialog needs some work. I used off the shelf dialog, but the URL is too long and not clickable. I will probably roll a custom one, should not be too difficult. I'm not too happy with the overall solution though - but I looked into the Qt tracker and there seem to be some changes in the works, so maybe i'll be able to improve it soon. |
Also, changed logging to be hidden by default. Use the following environment variable to show them:
|
I've built 4bb1222 and tested both OAuth2 redirect and OAuth2 OOB. At first, both failed as they were attempting to load a url that starts with
which returns a 404. It looks like it had remembered the url from an older version with the /api/0.6/ specifier. Once I realised and selected the correct url from the dropdown, login worked and I was able to upload a change. |
Thanks, I added a simple migration logic. For testing this, just run the new commit. To retest, edit |
Are you going to make a release any time soon or should distros just package a snapshot to make their package work again? |
I'm looking to merge this branch & tag a release in the following days. Any further improvements and fixes will be released separately. |
Fixed in PR #299, pushed 0.20.0 tag today. Please report any bugs in oauth2 implementation as separate tickets. |
Thank you for this app. Just a heads-up if you didn't know, that OSM is slowly deprecating HTTP Basic Auth and OAuth 1.0a in favor of OAuth 2 (see announcement and tracking issue).
Related: #104
The text was updated successfully, but these errors were encountered: