Page MenuHomePhabricator

Attempting to use OAuth for a SUL wiki where you do not have a user account causes 500 Internal Server Error
Closed, DuplicatePublic

Description

I noticed this today while putting together a quick and dirty tool to do a search on all wikis (using OAuth mostly because I could reuse my class). When the script came to certain wikis it wasn't getting a legitimate response back which at first I thought was just intermittent or I wasn't skipping closed wikis correctly.

After some troubleshooting I realized I was getting a '500 Internal Server Error' message back instead for those wikis and after checking a couple realized it was the 2 dozen or so wikis where I didn't yet have a local account. Obviously fixing that was easy (I clicked over to those wikis, my account auto created, and I ran the search again) this doesn't seem to be how we want the process to go.

For closed/fishbowl/private wikis I get a relatively nice json response saying that I don't have an account there which works well. I guess, at least, sending a message like that here would be nice. I would prefer, however, that it just auto created the account as if I was 'visiting' for the first time since I kind of am just in the form of my oauth token. My working assumption (based on no real information and just on the symptoms) is that the wiki doesn't return a 'no account found' error because it hits a snag when it finds my oAuth information in the centralWiki but doesn't find my local user account and so 'freaks out' and throws an error.


Version: unspecified
Severity: normal
Whiteboard: aklapper-moreinfo

Details

Reference
bz62308

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:04 AM
bzimport set Reference to bz62308.
bzimport added a subscriber: Unknown Object (MLST).
Anomie added a comment.Mar 6 2014, 3:24 PM

I suspect this may be the same issue as bug 62312; do the wikis with the problem also have CirrusSearch (even if not by default)?

Otherwise, it would be helpful to find the backtrace for the cause of the error, which means having the timestamp and wiki for an error message and checking /a/mw-log/exception.log (or possibly /a/mw-log/fatal.log) on fluorine. Feel free to ping me on IRC if you need help with that.

(In reply to Brad Jorsch from comment #1)

I suspect this may be the same issue as bug 62312; do the wikis with the
problem also have CirrusSearch (even if not by default)?
Otherwise, it would be helpful to find the backtrace for the cause of the
error, which means having the timestamp and wiki for an error message and
checking /a/mw-log/exception.log (or possibly /a/mw-log/fatal.log) on
fluorine. Feel free to ping me on IRC if you need help with that.

Hmmm, possible though no clue, it was only the wikis listed below when I did it and they all fixed themselves after I visited them and autocreated (I checked the log each time) my current account doesn't cause the issue anymore of course but when I get a chance tonight I'll switch my dev version to try using my personal account or perhaps my old public computer account which will have a ton of unvisited sites to see how that goes. Will report back here.

Wikis which failed the first time:
bewikisource
brwikisource
elwikinews
fawikinews
kowikiversity
liwikibooks
orwiktionary
sawikiquote
sawikisource
sahwikisource
slwikiversity
sqwikinews
arwikimedia
bdwikimedia
bewikimedia
cowikimedia
dkwikimedia
etwikimedia
fiwikimedia
mkwikimedia
mxwikimedia
nlwikimedia
nowikimedia
plwikimedia
ruwikimedia
sewikimedia
trwikimedia
uawikimedia

Anomie added a comment.Mar 7 2014, 5:50 PM

(In reply to James Alexander from comment #2)

Wikis which failed the first time:

All those do happen to have CirrusSearch enabled. Conclusive proof would be a backtrace though.

Looking for bewikisource, brwikisource, elwikinews, and fawikinews as examples, the only exceptions I see since 2014-03-05 are variations on this:

2014-03-06 13:52:10 mw1207 bewikisource: [d4386a1c] /w/api.php Exception from line 36 of /usr/local/apache/common-local/php-1.23wmf16/extensions/OAuth/api/MWOAuthAPI.setup.php: The authorization headers in your request are for a user that does not exist here
#0 /usr/local/apache/common-local/php-1.23wmf16/extensions/OAuth/api/MWOAuthAPI.setup.php(103): MWOAuthAPISetup::makeException('mwoauth-invalid...')
#1 [internal function]: MWOAuthAPISetup::onUserLoadFromSession(Object(User), NULL)
#2 /usr/local/apache/common-local/php-1.23wmf16/includes/Hooks.php(206): call_user_func_array('MWOAuthAPISetup...', Array)
#3 /usr/local/apache/common-local/php-1.23wmf16/includes/GlobalFunctions.php(4008): Hooks::run('UserLoadFromSes...', Array, NULL)
#4 /usr/local/apache/common-local/php-1.23wmf16/includes/User.php(1007): wfRunHooks('UserLoadFromSes...', Array)
#5 /usr/local/apache/common-local/php-1.23wmf16/includes/User.php(300): User->loadFromSession()
#6 /usr/local/apache/common-local/php-1.23wmf16/includes/User.php(1836): User->load()
#7 /usr/local/apache/common-local/php-1.23wmf16/includes/User.php(2959): User->getId()
#8 /usr/local/apache/common-local/php-1.23wmf16/extensions/CirrusSearch/includes/Hooks.php(61): User->isLoggedIn()
#9 /usr/local/apache/common-local/php-1.23wmf16/extensions/CirrusSearch/includes/Hooks.php(45): CirrusSearch\Hooks::initializeForUser(Object(User))
#10 [internal function]: CirrusSearch\Hooks::apiBeforeMainHook(Object(ApiMain))
#11 /usr/local/apache/common-local/php-1.23wmf16/includes/Hooks.php(206): call_user_func_array('CirrusSearch\Ho...', Array)
#12 /usr/local/apache/common-local/php-1.23wmf16/includes/GlobalFunctions.php(4008): Hooks::run('ApiBeforeMain', Array, NULL)
#13 /usr/local/apache/common-local/php-1.23wmf16/api.php(73): wfRunHooks('ApiBeforeMain', Array)
#14 /usr/local/apache/common-local/w/api.php(3): require('/usr/local/apac...')
#15 {main}

If that's your errors, then this is the same as bug 62312.

Note that Gerrit change 117189 has been merged in time for 1.23wmf18. If you can somehow test this against testwiki, test2wiki, testwikidatawiki, or mediawiki.org and see if it's fixed after tomorrow's deploy, that could be helpful.

(In reply to Brad Jorsch from comment #4)

Note that Gerrit change #117189 has been merged in time for 1.23wmf18. If
you can somehow test this against testwiki, test2wiki, testwikidatawiki, or
mediawiki.org and see if it's fixed after tomorrow's deploy, that could be
helpful.

James Alexander: Is this still an issue or obsolete?

(In reply to Brad Jorsch from comment #4)

Note that Gerrit change #117189 has been merged in time for 1.23wmf18. If
you can somehow test this against testwiki, test2wiki, testwikidatawiki, or
mediawiki.org and see if it's fixed after tomorrow's deploy, that could be
helpful.

James Alexander: Is this still an issue or obsolete?

Aklapper changed the task status from Open to Stalled.Nov 25 2014, 7:47 PM
Ragesoss changed the task status from Stalled to Open.Nov 26 2014, 9:24 PM
Ragesoss added a subscriber: Ragesoss.

This is definitely still an issue. It's the same thing I described in T74791, which I'm not sure why it was resolved the way it was. If you create a new account, you cannot use OAuth until you've visited another wiki with that account.

(I just created an account and tried it to confirm that the problem is still present.)

Ragesoss triaged this task as High priority.Nov 26 2014, 9:25 PM
Ragesoss set Security to None.

Umm, what does T72469 have to do with this?

My mistake. bz72469, which T74791 was marked as a duplicate of. Here's the one I meant: T74469