Streetcomplete: Authorize OSM access not working

[PanderMusubi]

Authorize OSM access is not working in version 1.0 on LineageOS with GAPPS pico and F-Droid. I can choose to authorize via OsmAnd~, which doesn't work at all and results in a place in the middle of the ocean. Other way of authorization is via Firefox. That results in an error Unable to reach the authorization server. However, when I open Firefox manually, I see a tab opened for authorization. Logging in has no further effect on the app where I remain Not yet authorized.

Trying to downgrade to 0.13, to test that, resulted in an unknown error. De-installing 1.0 and installing 0.13 worked. There authorization works properly as it seems to be a different implementation.

[westnordost]

Downgrading is not implemented, any downgrades that involve a different DB scheme will not work. To downgrade, you'd need to clear the data.

The middle of the ocean bug is known, that's the current LOST (third party library).

Can you be more specific when exactly the auth fails and ideally what is logged on console?

What browser do you use? Did you try another browser?

Do you use something other than the normal name+pw? (I.e. Google etc)

Yes, v0 uses a WebView inside the app, v1 uses the external browser as it is recommended in the OAuth protocol and necessary when using Google login.

Am 24. Juli 2017 07:53:05 MESZ schrieb Pander [e-mail]:

Authorize OSM access is not working in version 1.0 on LineageOS with
GAPPS pico and F-Droid. I can choose to authorize via OsmAnd~, which
doesn't work at all and results in a place in the middle of the ocean.
Other way of authorization is via Firefox. That results in an error
Unable to reach the authorization server. However, when I open
Firefox manually, I see a tab opened for authorization. Logging in has
no further effect on the app where I remain Not yet authorized.

Trying to downgrade to 0.13, to test that, resulted in an unknown
error. De-installing 1.0 and installing 0.13 worked. There
authorization works properly as it seems to be a different
implementation.

--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/westnordost/StreetComplete/issues/413

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[westnordost]

Also see #386
Similar problem or different problem?

[PanderMusubi]

Most probably the same issues as I see in the screen recording. Note that GAPPS pico is lacking the Android System WebView app, but installing that doesn't make a difference.

[westnordost]

You need to elaborate in the things I asked you because that issue was fixed.

Am 24. Juli 2017 17:35:53 MESZ schrieb Pander [e-mail]:

Most probably the same issues as I see in the screen recording. Note
that GAPPS pico is lacking the Android System WebView app, but
installing that doesn't make a difference.

--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/westnordost/StreetComplete/issues/413#issuecomment-317462181

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[PanderMusubi]

"Can you be more specific when exactly the auth fails and ideally what is logged on console?" -> Which console?

"What browser do you use?" -> Firefox, latest stable from Google Play.

"Did you try another browser?" -> I installed Android System WebView app but didn't matters

"Do you use something other than the normal name+pw? (I.e. Google etc)" -> username + passwor, worked before with 0.13

does this answer your questions?

[westnordost]

Almost. I need to know when exactly the message comes: Before Firefox even opens or after you entered your credentials in Firefox on returning to the app?

Regarding the console: Would you do you me a favour and download a log reader like https://play.google.com/store/apps/details?id=com.nolanlawson.logcat&hl=en or similar, leave it running in the background while trying to authenticate and tell me what is being logged on the console from streetcomplete when the authorization fails?

[PanderMusubi]

Firefox never comes to the foreground. If I go to Firefox, I see the opened tabs. If I login, it does not return to StreetComplete. If I go to StreetComplete manually, I am not logged in. Plenty of combination of this results in not getting logged in.

Do you have an alternative log reader from F-Droid I could use as I prefer apps from there?

[PanderMusubi]

http://fdroid.org/packages/com.tortel.syslog/ or http://fdroid.org/packages/org.jtb.alogcat/ ?

[westnordost]

Any should do the job.

[westnordost]

Firefox never comes to the foreground. If I go to Firefox, I see the opened tabs.

Wow, this is weird. How can it be possible that any app opens another app "in the background"?? Can you close all those opened tabs please and try to reproduce it with a "fresh" Firefox? (No openstreetmap tabs opened). Is the behavior that a tab opened but Android did not switch from StreetComplete to Firefox reproducable?

[krzyk]

@PanderMusubi Maybe you have a tab queue enabled in Firefox (https://support.mozilla.org/en-US/kb/open-links-background-later-viewing-firefox-android)?

Is Firefox set as the default browser? (https://support.mozilla.org/en-US/kb/make-firefox-default-browser-android#w_android-6-marshmallow-and-higher)

[jacopofar]

Same problem here using Firefox on Android 7.1 and authenticating to OpenStreetMap using the Google account. I see the requested to authorize the application inside the browser, give it and the tab closes. Then Streetcomplete says there was a problem connecting to the server and can't login.

Subsequent requests to authenticate open the browser which closes immediately, as described above.

Can I help providing further informations? Really like the idea, hope use it soon

[jacopofar]

Ok, temporarily disabling the tab queue in Firefox I could log in.

[westnordost]

Oh man... a neverending story. I summarize:

1. OAuth standard says that it is best practice to use an external browser for authentication instead of a WebView (see #265)
2. Google blocks OAuth login with WebViews - must always use external browser (see #348 and Google developers blog) since April
3. I reimplement the OAuth process to use the external browser
4. Firefox launches the callback url in an unusual way that breaks the OAuth process in a browser (see #386), but there is a workaround
5. Firefox has a Feature (tab queue) that effectively breaks the OAuth process in a browser (this ticket)

Result: Login with OAuth is broken either way when using the Google Account and Firefox as a browser, no matter what.

Who is to blame? Google, for enforcing the use of an external browser.
If it is possible for a browser to fuck up the OAuth workflow that much on an smartphone, then the workflow should obviously not rely on the communication between the app and a browser... There is a difference between "Best practice" (mentioned in a draft) and obligation.

Anyway, I fear this problem cannot be solved, as described aboce.

[westnordost]

The stack trace is:

07-25 11:19:21.889 28143-28143/de.westnordost.streetcomplete E/OsmOAuthDialogFragment: Error during authorization
oauth.signpost.exception.OAuthNotAuthorizedException: Authorization failed (server replied with a 401). This can happen if the consumer key was not correct or the signatures did not match.
    at oauth.signpost.AbstractOAuthProvider.handleUnexpectedResponse(AbstractOAuthProvider.java:243)
    at oauth.signpost.AbstractOAuthProvider.retrieveToken(AbstractOAuthProvider.java:193)
    at oauth.signpost.AbstractOAuthProvider.retrieveAccessToken(AbstractOAuthProvider.java:108)
    at de.westnordost.streetcomplete.oauth.OsmOAuthDialogFragment$RetrieveAccessTokenTask.doInBackground(OsmOAuthDialogFragment.java:235)
    at de.westnordost.streetcomplete.oauth.OsmOAuthDialogFragment$RetrieveAccessTokenTask.doInBackground(OsmOAuthDialogFragment.java:231)
    at de.westnordost.streetcomplete.util.InlineAsyncTask.doInBackground(InlineAsyncTask.java:24)
    at de.westnordost.streetcomplete.util.InlineAsyncTask.doInBackground(InlineAsyncTask.java:11)
    at android.os.AsyncTask$2.call(AsyncTask.java:292)
    at java.util.concurrent.FutureTask.run(FutureTask.java:237)
    at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:231)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
    at java.lang.Thread.run(Thread.java:818)

The tab queue feature immediately sends the user back to the app the user was coming from (calls onResume()) which in turn assumes that the authentication has been finished and tries to continue the authentication process by retrieving the access token.
Probably it is possible to detect at this point whether the user already did the authentication or not by looking at the verifier.

Implementation should:

1. detect that
2. show the loading-window while the app is waiting for the user to switch to Firefox to authenticate

[PanderMusubi]

Perhaps get some advice from Firefox as they might have some extra solutions of plans in the near future. More apps will have the same challenge. Depending on Android System WebView app could be a temporarily solution. Non-custom ROMs all have it.

[PanderMusubi]

Android has also another default system browser, which is used to sign into free wifi networks (not the WebViews), could you use that to do the authorization?

[westnordost]

The system browser has been removed (and replaced with Chrome) with newer Android versions, as far as I know.

[PanderMusubi]

On LineageOS, there is a browser for wifi login. perhaps you could detet if that is there, use, that, it not, use webview, if not, use default user browser (probably firefix/chromium)

[westnordost]

Turns out this was pretty easy to fix.

[easyKL]

neither Firefox nor OsmAnd~(2.6.3) were able to authorize StreetComplete.
Tried with Chrome (59) and it went smoothly ;)

[westnordost]

Version 1 or 1.1? (this has been fixed in 1.1)

[easyKL]

Yes, I've seen the Closed label for this issue. I just wanted to say what I did :))
Yes, I'm still in 1.0 (F-Droid here)
THX!!!

[zorun]

I still have an authorization issue on LineageOS, with SC version 1.3 from F-Droid.

It opens the LineageOS broswer (Jelly), I can login to OSM and authorize the app, but then instead of returning to SC, it redirects to my search engine with a search query streetcomplete://oauth?oauth....

So, either the LineageOS browser does not take into account the streetcomplete:// kind of URL, or there is something wrong with SC.

[westnordost]

That sound's like LineageOS's browser's fault.

If LineageOS browser does not call StreetComplete, then StreetComplete can not answer.

[zorun]

I tried with another simple browser (de.baumann.browser) and it worked, so you must be right.

Do you have any pointer to the method you use to communicate with the browser, so that I can report the bug against LineageOS?

[westnordost]

It is a normal intent-filter. The code:

https://github.com/westnordost/StreetComplete/blob/master/app/src/main/AndroidManifest.xml#L35-L41

[kousu]

I'm seeing the issue @zorun sees on LineageOS too, which seems to be a duplicate of #386 ? With the stock browser in LineageOS, the search engine is opened to streetcomplete://oauth?oauth_token=xxxxxxxxxxx&oauth_verifier=xxxxxxxxxxxxx.

I also cannot loogin see it with https://f-droid.org/wiki/page/com.stoutner.privacybrowser.standard. That, instead of opening the search engine, says net::ERR_UNKNOWN_URL_SCHEME.

[kousu]

p.s. here's a permalink to that intent-filter https://github.com/westnordost/StreetComplete/blob/a838a361d7fe95789b64fad1cd3f78afbd98fa04/app/src/main/AndroidManifest.xml#L45

[zorun]

@kousu thanks

In the end I haven't reported the bug to LineageOS because of their weird policy of opening the bug tracker only at certain times.

[westnordost]

I'd say it is a missing feature, not a bug. But I haven't even found their bugtracker.

On 5 October 2017 22:14:15 CEST, zorun [e-mail] wrote:

@kousu thanks

In the end I haven't reported the bug to LineageOS because of their
weird policy of opening the bug tracker only at certain times.

--
You are receiving this because you modified the open/close state.
Reply to this email directly or view it on GitHub:
https://github.com/westnordost/StreetComplete/issues/413#issuecomment-334579196

--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[kousu]

It's a bug from over here 😖, because this behaviour totally blocks StreetComplete from being usable. I would have uninstalled it if I hadn't dug into this bug tracker and seen the tip about de.baumann.browser.

You're not going to be able to get everyone to behave themselves, so what if the Authorize button popped up a "Complete the authorization flow or paste the resulting URL here" modal dialog? That way StreetComplete should work with any browser; if it doesn't work with the browsers on-system at least we have a fallback.

[kousu]

Or, do what desktop apps do: run a shim webserver inside of StreetComplete and set the OAuth return url to http://localhost. I implemented this and it works, though you need to lie to your own OAuth library about that response coming back through https.

Or maybe go back to the embedded webkit browser, where you have control. I'm pretty sure this is what Thunderbird does; even it it's against spec it works, at least, and you can go off happily mapping.

[kousu]

I had an idea this morning: as a sort of compatibility glue, what if the Authorize button gave a "Complete the authorization flow or paste the resulting URL here" modal dialog? That way StreetComplete should work with any browser.

On October 5, 2017 4:14:16 PM EDT, zorun [e-mail] wrote:

@kousu thanks

In the end I haven't reported the bug to LineageOS because of their
weird policy of opening the bug tracker only at certain times.

--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/westnordost/StreetComplete/issues/413#issuecomment-334579196

--
kousu

[Moini]

Issue is still present with default browser on LineageOS 15.1 - it calls the 'streetcomplete' url. Unfortunately, I cannot try out the workaround of just using a different browser currently, because the last Lineage update is stuck in reboot...

[matkoniecz]

See https://github.com/westnordost/StreetComplete/issues/413#issuecomment-334698620 and https://github.com/westnordost/StreetComplete/issues/413#issuecomment-328339501 - problem is on side of Lineage and will exist untill Lineage fixes it.

Are you aware how bugs in Lineage software are supposed to be reported?

[Moini]

Yes - that comment was intended not for the maintainer, but for others that find the issue here by doing a web search. Sorry for the noise.

[ENT8R]

I reported the issue at the issue tracker of LineageOS a long time ago and there is still no response: https://jira.lineageos.org/browse/BUGBASH-1393

[Moini]

I've updated the issue, telling them it's still present in 15.1.

[singpolyma]

I am getting exactly this error with latest firefox from play store or even when changing my default browser to chrome. Browser comes up, I log in to OSM, I authorize the app, and then I am taken back to the app but get this "Unable to reach the authorization server" error.

[matkoniecz]

What is your phone and Android version? Are you using Android or one of special versions like Firefox Focus/Firefox Preview etc?

[singpolyma]

What is your phone and Android version? Are you using Android or one of
special versions like Firefox Focus/Firefox Preview etc?

Android: 7.7.1
Phone: Nokia 2
Model: TA-1035

Browser: Latest Firefox from Google Play (but I also tried with Chrome and
got the same result).

One thing: my phone has very little RAM, so usually switching apps and
switching back causes the first app to reload. Maybe some state is not
being saved when Android OOMs the app after opening the browser?

[matkoniecz]

That would make sense and would be sadly probably unfixable (or to be more exact - not fixable in way that is reasonable to implement).

[singpolyma]

@matkoniecz really? I thought Android basically assumed any app could be "killed" at any time and everything is meant to be persisted temporarily to avoid this?

In any case -- can you think of any workaround I could maybe try to keep the app "open" long enough to complete the login?

[matkoniecz]

I may be wrong and there may be way too fix it. Opening a new issue may be a good idea (not sure whatever the author of the app noticed this discussion in a closed issue).

I may be wrong but I think that browser + StreetComplete In this situation is de facto a single app during this operation - with bigger resource requirements.

[westnordost]

I noticed it now

[mimi89999]

I cannot authorize StreetComplete on LineageOS 17 (Android 10). When clicking authorize, my default browser (Firefox preview) opens, I am asked to connect to my OSM account, then I grant access to StreetComplete and then nothing happens. When I return to StreetComplete I see the loading message.

[westnordost]

This is likely an issue with "Firefox preview". (What is Firefox Preview?)

Though, perhaps I should revert to the old solution - using a WebView within the app. no external dependency on a browser necessary.

[mimi89999]

That's Firefox preview: https://play.google.com/store/apps/details?id=org.mozilla.fenix

[PanderMusubi]

@mimi89999 can you test it with https://f-droid.org/en/packages/org.mozilla.fennec_fdroid/ ?

[mimi89999]

I can confirm that it works fine with Fennec F-Droid

[photoangell]

I'm getting this on stock Android 8.1.0 with chrome installed. I had previously attempted with firefox, bromite, etc. and reinstalled Chrome to test this but no luck

[photoangell]

tried with Fennec as well, still getting the error
I can see loads of auth tokens in my osm account, it's just the response being passed back is not being handled somehow....

[photoangell]

ok. managed to solve it. downloaded release 0.13 (which uses a different auth method), authorised and then downloaded latest version.

[okias]

I can confirm with 16.1 - 17.3 that auth doesn't work with Firefox Fenix (Preview) and integrated browser. In both scenarios I get "Unknown protocol"

[okias]

still broken :-1: (version 18.0)

[westnordost]

It is fixed in the development branch and will be released for the next major

[okias]

It is fixed in the development branch and will be released for the next major

Thank you! For next time, you can use tag to mark this commit by

Fixes: #413

which will link fix with bug and also appears in bug, so people will instantly know it's fixed and bug closes itself :)

[okias]

I'd like to start contributing, any sign of alpha/beta release? @westnordost

[westnordost]

No, will still take time. Just use Firefox or Chrome to login

On 7 April 2020 00:14:29 CEST, David Heidelberg [e-mail] wrote:

I'd like to start contributing, any sign of alpha/beta release?
@westnordost

[okias]

it accept my authorization, but then it re-ask after every change. And nothing gets pushed onto osm servers. I'll probably need this fix.