Page MenuHomePhabricator

Some old accounts unable to login
Closed, ResolvedPublic

Description

It appears that some users are unable to login to the platform at the OAuth stage. All users reporting this issue so far have pre 2006 accounts: DESiegel, Gamaliel, Pajz.

Original description:
Hello! User:DESiegel on en.Wikipedia tried to sign on with the single sign on and received an internal server error, preventing them from signing up on the new process. This is the error they receive https://wikipedialibrary.wmflabs.org/oauth/callback/?oauth_verifier=3cd3782482fa177c8d16e0abc8aa58b8&oauth_token=5222cbd429cf8928dc9cff009a5ba9f4

Relevant thread on their talk page: https://en.wikipedia.org/w/index.php?title=User_talk:DESiegel&oldid=789850955 the thread is WP:Newspapers.com

Can someone take a look at this? Thanks!

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJul 10 2017, 1:10 AM
Cameron11598 updated the task description. (Show Details)Jul 10 2017, 1:14 AM
Samwalton9 triaged this task as High priority.Jul 10 2017, 8:14 AM
Samwalton9 edited projects, added Library-Card-Platform; removed The-Wikipedia-Library.
Samwalton9 moved this task from Incoming tasks to Major Bugs on the Library-Card-Platform board.

User:Gamaliel is reporting a similar issue.

The accounts were created in February 2004 and February 2005, so I suspect this is another (T164300) issue with old accounts.

Samwalton9 renamed this task from Unable to Signup on the New Wikipedia Library page to Some old accounts unable to login.Jul 10 2017, 8:21 AM
Samwalton9 assigned this task to jsn.sherman.

Also worth noting that Gamaliel logged in successfully with an alternate account created more recently.

Samwalton9 added subscribers: pajz, Samtar.

User:Pajz having the same issue. Account created May 2006.

Samwalton9 updated the task description. (Show Details)Jul 10 2017, 11:22 AM
Gamaliel added a subscriber: Gamaliel.

Hmm, having spent some time chasing this down, I think we're not getting as much back from oauth on these accounts. I've worked up some changes in the staging environment and was hoping that one of our affected users could try logging in there. Basically, I've switched out some of our references to the oauth return data to api calls.

jsn.sherman added a comment.EditedJul 11 2017, 1:29 AM

Sidenote: the issue with DESiegel looks to be separate from the others. DESiegel's issue seems to be a bonafide oauth exception, where the others look to be incomplete info from the IdP.

DESiegel added a subscriber: DESiegel.EditedJul 11 2017, 3:03 AM

Hmm, having spent some time chasing this down, I think we're not getting as much back from oauth on these accounts. I've worked up some changes in the staging environment and was hoping that one of our affected users could try logging in there. Basically, I've switched out some of our references to the oauth return data to api calls.

I attempted to log in using the link to the staging environment and got the same result as before. It displayed a message asking for permission to share information, and after I clicked "allow" I got the unhelpful "Internal server error" message again, at URL: https://twlight-staging.wmflabs.org/oauth/callback/?oauth_verifier=7e7a000f430b7f44cf3f5dc7af40c09f&oauth_token=9d982065428a6b497e9e20dc75e784f0. However i was able to sign up for Phabricator using my MediaWiki credentials (after re-confirming my email). I hope these details are helpful.

Hmm, having spent some time chasing this down, I think we're not getting as much back from oauth on these accounts. I've worked up some changes in the staging environment and was hoping that one of our affected users could try logging in there. Basically, I've switched out some of our references to the oauth return data to api calls.

Still doesn't work for my account, I'm getting the same internal server error.

I flipped on some much more detailed logging for the authentication process in staging. If impacted users attempt to login there again, I'll be able to examine all of the data coming back from oauth and our api calls.

I flipped on some much more detailed logging for the authentication process in staging. If impacted users attempt to login there again, I'll be able to examine all of the data coming back from oauth and our api calls.

Still unable to log in via the staging environment or the library card page.

pajz added a comment.Jul 11 2017, 3:27 PM

Still unable to log in via the staging environment or the library card page.

Same here.

Well we found at least part of the problem:
registration date for @pajz coming back oauth

u'registered': None

From the global userinfo api we get back the following:

u'registration': u'2010-12-17T15:51:41Z'

I updated the code on staging to try the date from the api if it can't get one from oauth.

@pajz can you try logging into staging again?

pajz added a comment.Jul 11 2017, 10:36 PM

Ok, I just clicked on "Log in", but was immediately prompted with the "Internal server error" page again.

hmm @pajz I just restarted some services. Can you try again in a private browsing session? This should force you to go through the whole process again, including logging into meta.

pajz added a comment.EditedJul 11 2017, 10:48 PM

@jsn.sherman Following your suggestion, I now (1) opened https://twlight-staging.wmflabs.org/ in a new icognito window, (2) clicked on "Log in", which prompted me to the log in screen on Meta, then (3) logged in with my credentials and (4) entered the 2FA code. I was then immediately shown the "Internal server error" again.

jsn.sherman added a comment.EditedJul 11 2017, 10:52 PM

@pajz this has been very useful, as I've been watching the server step through the authentication process. Can you test again? You shouldn't have to start from scratch this time, just clicking the login button again on staging should suffice.

pajz added a comment.EditedJul 11 2017, 10:56 PM

@jsn.sherman I now opened https://twlight-staging.wmflabs.org/ in my normal browser window, clicked on "Log in", then was shown a "Welcome to the Wikipedia Library Card Terms of Use and Privacy Statement!" dialogue. I accepted the terms of use, which got me to the "Editor profile information for Pajz" with a "Start new application" button. I suppose that means it now worked?

@pajz yep, we've discovered the cure for your account. I'll need to clean up the changes I've made before I can push them to the real site though. It would be great to get a test from @Gamaliel and @DESiegel on staging as well. I may have to make more changes to get them logging in.

Gamaliel added a comment.EditedJul 12 2017, 3:28 AM

I'm able to log into https://twlight-staging.wmflabs.org/ now! Still unable to log into https://wikipedialibrary.wmflabs.org/ though.

I was able to log in and apply through the staging url , although the resulting profile lists my date of joining Wikipedia as 2010, which is several years late, and lists my group memberships as autoconfirmed, ignoring my admin group membership, and several others (online course volunteer for example). i didn't try the basic address.

I was able to log in and apply through the staging url , although the resulting profile lists my date of joining Wikipedia as 2010, which is several years late, and lists my group memberships as autoconfirmed, ignoring my admin group membership, and several others (online course volunteer for example). i didn't try the basic address.

Based on this, I looked again via the staging url. My date of joining is also incorrect (2008 instead of 2004) and my admin group membership is also missing.

User groups currently only shows your Meta user groups (T169628). I assume that the join date is also shown the date your account was joined/merged/created on Meta. Filed T170372 to get that sorted.

Thank you all for helping to solve this problem!

Tgr added a subscriber: Tgr.Jul 12 2017, 2:04 PM

registration date for @pajz coming back oauth

u'registered': None

From the global userinfo api we get back the following:

u'registration': u'2010-12-17T15:51:41Z'

The first is the registration date on the wiki which you are sending the request to (can be null if the user registered before MediaWiki started logging registrations, which is 2008ish IIRC), the second is the creation date of the global account (same as first registration for recent users, SUL merge date for older ones).

In general, OAuth does not know about CentralAuth (apart from central user IDs, which is a core MediaWiki feature) so all data given by /identify will refer to the local wiki. Use the CentralAuth APIs if that isn't what you want.

I think the desired result is the the first local registration date for a user. the global user info request is returning the home wiki from the sul merge, so I'm thinking that an additional api call to that wiki would get the earliest date possible.

Tgr added a comment.Jul 12 2017, 2:34 PM

Most of the time, although home wiki was determined by edit count at the time of the account unification, which is not necessarily the same as registration date.

Per our discussions in T170372 and T169628 I think we have a plan in place to solve this well enough for our needs.

How long will it be before the fix is made to the real server, so that I can log in and apply, as I was attempting to do when this issue was discovered? Do yo know? I tried to today and was not able to yet.

@DESiegel We're rolling a large number of changes to the platform over this weekend, and this is one of them. I'll post an update here when you should be good to go.

This issue should be resolved on the live website. Please let us know if you're still having trouble signing in.

I'm in, thank you!

Samwalton9 closed this task as Resolved.Jul 17 2017, 9:07 AM