If I log in using this link (https://www.mediawiki.org/w/index.php?title=Special:UserLogin&returnto=Special:OAuth/authorize&returntoquery=oauth_token%3Df97d76d6ec67bde6719952217d5ab80e%26oauth_consumer_key%3Dd5aa23a6b7a6d61e21ba1bb725c212fe) on my iPad mini to log in and authorise the Wikidata Game on toollabs access to my account (Vidar?) I'm taken to this site (screenshot below; https://m.mediawiki.org/wiki/Special:CentralLogin/complete?token=39880826259b573205f3c40ad7ae8570) after logging in, instead of the "Allow-dialog" which is visable on desktop.
Description
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Duplicate | BUG REPORT | None | T298440 "Other languages" links to desktop version instead of mobile | ||
Open | None | T156847 Core should be aware of the domain it is running on and render mobile domains where necessary | |||
Resolved | Magnus | T112730 Failure to OAuth after login on mobile |
Event Timeline
@Josve05a: What security are you trying to set on this task? You won't be able to move it out of the NDA restrictions simply by removing the project, but I can change the policies for you if you want.
I tried first to remove the security, by setting it to 'none' (and at the same time I removed the nda-project). That didn't work, and sine I have no way to change the policy after I created the task, it it stuck as this policy. Just set it as public.
The error message is centralauth-error-nologinattempt ("No active login attempt is in progress for your session.").
Can't reproduce (either on desktop or on an Android phone):
- go to https://tools.wmflabs.org/wikidata-game/ in private browsing mode
- click in the link in "log in here"
- edit the url from www.mediawiki.org to m.mediawiki.org
- log in
- authorization dialog shows up as expected.
How I did:
- Go to https://tools.wmflabs.org/wikidata-game/
- click the link "log in here"
- Log in. (You should see the desktop view of the log in screen; i.e. do not change to m.mediawiki manually)
- You are now redirected to the mobile site (screenshot above)
To get it to work, I afterwards repeat step 1 and 2 and will be taken to the proper Alow-dialog (on desktop site) without having to log in again.
Do you get the same result if you repeat the steps? Also if you repeat them in private browsing mode?
No, if I click the "log in here"in the second step, affter having done all 4 steps once already in this session, I'm taken to the desktop "Allow-dialog" directly. So it's the redirecting from the login screen on "desktop-view" to the dialog in "mobile view" which is broken somehow. However, if I start a new session (restart the browser, or enter private mode, or log out from wiki) I can reproducae all the steps once again.
Still can't reproduce, your steps work fine for me (in desktop Chrome in private mode). What device and browser are you using? What is the full URL for that error message?
In step 2 I'm redirected to https://www.mediawiki.org/w/index.php?title=Special:UserLogin&returnto=Special:OAuth/authorize&returntoquery=oauth_token%3De94cd7cc12a91889d00f124f49237fed%26oauth_consumer_key%3Dd5aa23a6b7a6d61e21ba1bb725c212fe
I press log in on that screen, and I'm redirected to https://m.mediawiki.org/wiki/Special:CentralLogin/complete?token=0272357381eda2e9c47a65b7d7831e27
I've confirmed this on my Android phone. As a logged-out mediawiki.org user (copy of Josve05a's steps):
- Go to https://tools.wmflabs.org/wikidata-game/
- click the link "log in here"
- Log in. (You should see the desktop view of the log in screen; i.e. do not change to m.mediawiki manually)
- You are now redirected to the mobile site (screenshot above)
The mobile login form is no different from desktop login form so I expect there is some code that is not being loaded e.g. doesn't have appropriate target set.
The exception is due to the mobile redirect-- you gave your username and password to www.mediawiki.org, but you're trying to complete the login on m.mediawiki.org. If the wikidata-game updates its authorization redirect from,
https://www.mediawiki.org/w/index.php?title=Special:OAuth/authorize&oauth_token=...
to
https://www.mediawiki.org/wiki/Special:OAuth/authorize?oauth_token=...
then it should Just Work.
Who is investigating this issue? It seems pretty bad. I hit this error when trying to log in to the English Wikipedia on my phone the other day.
It seems pretty rare. You need to be 1) on mobile 2) logged out on Phabricator or whatever else you are using 3) sent for tool authorization to a wiki where you are not logged in 4) the tool must be using the non-canonical form of the URL; and even then it does not happen deterministically. And it has an obvious workaround (login first, then authorize).
What does this mean? Do we log this error anywhere? How many times are we raising this error per day?
As far as I know, my English Wikipedia user account and Phabricator are completely distinct. Perhaps the issue I'm hitting is separate from this issue (T112730), T95221, and T119343. If so, I can file a new task if you would prefer that.
And it has an obvious workaround (login first, then authorize).
I experienced this issue when logging in to a MediaWiki wiki. What specifically do you think I should authorize in order to log in to the wiki with a regular user account?
Yes, if you experience the same error without any OAuth tool being involved, a separate task would helpful. Might or might not be the same underlying issue, but at a minimum a login will be a lot easier to reproduce and debug than a full authorization flow.
Just collecting some tasks here related to broken login behavior.
- T53789: Attempting to login on en.m.wikipedia.org in desktop browser shows warning: "No active login attempt is in progress for your session."
- T56123: Error message after Commons registration from campaign link on mobile
- T64244: New users not created on loginwiki in Labs
- T64484: intermittent but frequent Login error on beta labs
- T65821: login error
- T95221: Using the MediaWiki login to Phabricator on mobile, got a "No active login attempt is in progress for your session." error on CentralLogin
- T125139: Login to login.wikimedia.org fails with "No active login attempt is in progress for your session."
- T140127: "Can only obtain a centralauthtoken when using CentralAuth sessions" during auto-creation
- T140853: Central login fails when user logs in via redirect flow
- T145545: "No active login attempt is in progress for your session." when trying to log in on wikisource.org
- T145771: Fatal exception on en.wp trying to register to a course: "CAS update failed"
- T146122: Loging into Phabricator with MediaWiki account on mobile device can cause endless loop
This stiill appears to be an issue. I'm unable to login to Phabricator on mobile, seeing the same error as in the original post.
I am seeing the error for centralauth-error-nologinattempt on mobile after inputting my two factor auth code.
This is happening in the embedded browser in the Wikipedia app on iOS. Anecdotally, I think others have encountered this issue lately as well (cc @KStoller-WMF who I believe experienced this last week).YES! I just tried mobile login via OAuth on dashboard.wikiedu.org (while initially logged out on Wikipedia) and it worked smoothly! Until now, it's always thrown an error after login, and would only work if I was already logged on Wikipedia at the outset of the OAuth login flow.
Thank you Magnus!
I can't reproduce this today.
All of the OAuth login links I've tried (the one in task description, https://tools.wmflabs.org/wikidata-game/, https://phabricator.wikimedia.org/, https://dashboard.wikiedu.org) send me to the mobile login page when I'm using my phone today, and not to the desktop page as described in everyone's reproduction steps.
See T74186#9357590 for what I think was going on here.
Configured the tool to redirect to https://www.mediawiki.org/wiki/Special:OAuth/authorize instead of https://www.mediawiki.org/w/index.php?title=Special:OAuth/authorize, presumably.
FWIW rEMFRee049b8e45e0: Handle mobile URLs for other wikis fixed the login issue so even if an app used the wrong URL today, I think login would work (they would just have to do it on the desktop site which is bad for UX). We should set up a test consumer which uses the wrong URL and verify this.
Filed as T351988: Set up a test for authorizing an OAuth 1 app over a nice URL. Nothing actionable left here.