Last modified: 2011-01-25 00:38:13 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T23661, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 21661 - OpenID login drops returnto
OpenID login drops returnto
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
OpenID (Other open bugs)
unspecified
All All
: Normal major (vote)
: ---
Assigned To: Sergey Chernyshev
: patch
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-27 14:26 UTC by Shaun Phillips
Modified: 2011-01-25 00:38 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Patch for Bug 21661. (552 bytes, patch)
2009-12-07 20:46 UTC, Craig Box
Details
Fix for problem with redirect (only on first attempt to log in) (323 bytes, patch)
2010-04-19 15:55 UTC, Craig Box
Details

Description Shaun Phillips 2009-11-27 14:26:15 UTC
When accessing our mediawiki site via a link i.e. http://mywiki.symbian.org/w/index.php/Category:IT the link is lost and the homepage is shown after login with openid, problem does not occur when not using openid.
Comment 1 Sergey Chernyshev 2009-11-27 18:29:14 UTC
It did work for sure - I wonder when it stopped working.
Comment 2 Shaun Phillips 2009-12-07 14:52:44 UTC
Tried on another site and also different OpenIDs and it is not redirecting to the requested URL.
How is it supposed to work, is the requested stored locally during login?
Comment 3 Sergey Chernyshev 2009-12-07 15:21:19 UTC
Yes, I believe so.

I noticed that it works on TechPresentations.org but doesn't work on MediaWikiWidgets.org - will try to investigate.
Comment 4 Sergey Chernyshev 2009-12-07 15:27:48 UTC
Hmm. Interesting... it seems to work now. Looks like a hard bug to catch.
Comment 5 Shaun Phillips 2009-12-07 15:36:57 UTC
I have the problem consistently, you can test using my test site here http://tricky.dragonspell.com/tricky/, I currently have it setup so you have to login to view anything, just thought are there any other pages I need to make public i.e. $wgWhitelistRead = array ('Special:OpenIDLogin','Special:OpenIDFinish'); .

Here is a direct link to a page http://tricky.dragonspell.com/tricky/index.php/Setting_up_PHP_OpenID_with_MediaWiki_%26_Google_Apps
Comment 6 Sergey Chernyshev 2009-12-07 15:44:38 UTC
Actually, it worked just fine with my Google-powered OpenID.

I went to this page: http://tricky.dragonspell.com/tricky/index.php/Tricky:Community_Portal while being logged out.

Then I clicked on "Login with OpenID" link at the top right (which has Google icon for some reason) and it sent me to http://tricky.dragonspell.com/tricky/index.php?title=Special:OpenIDLogin&returnto=Tricky:Community_Portal - notice the returnto parameter.

Then I used Google account to log in and created an account on your wiki and then it brought me to the page that said "you're logged in, please return to Tricky:Community_Portal" with appropriate link.

It keeps me wonder if it depends on OpenID provider as well - will try to do more testing.
Comment 7 Shaun Phillips 2009-12-07 16:10:54 UTC
Works for me too using the OpenID link rather than the "You must log in to view other pages." link 

Trying on our live site, I notice that they are different.

http://mywiki.symbian.org/w/index.php?title=Special:OpenIDLogin&returnto=Symbian_Handbook  - Works

http://mywiki.symbian.org/w/index.php?title=Special:UserLogin&returnto=Symbian_Handbook  - Fails

So by the looks of it we need to change that link provided when the user needs to login to http://mywiki.symbian.org/w/index.php?title=Special:OpenIDLogin
Comment 8 Sergey Chernyshev 2009-12-07 16:17:17 UTC
UserLogin is not an OpenID login. If you click there, what do you do next to log in?
Comment 9 Shaun Phillips 2009-12-07 16:25:00 UTC
It takes you to the Special:OpenIDLogin page but without the &returnto parameter details, so the linked to page is lost.
Comment 10 Craig Box 2009-12-07 20:13:35 UTC
I should note we have $wgOpenIDOnly = yes, so I think the problem is in this hook (OpenID.hooks.php:8 or so)

                if ( $wgOpenIDOnly ) {
                        $list['Userlogin'] = array( 'SpecialRedirectToSpecial', 'Userlogin', 'OpenIDLogin' );

A call to http://example.org/w/index.php/Special:Userlogin?foo=bar&pie=nice gets rewritten to http://example.org/w/index.php/Special:OpenIDLogin with no query parameters.
Comment 11 Craig Box 2009-12-07 20:46:52 UTC
Created attachment 6861 [details]
Patch for Bug 21661.

Patch attached to fix issue.
Comment 12 Sergey Chernyshev 2009-12-07 23:08:52 UTC
Yes, this seems to be true for $wgOpenIDOnly where returnto gets dropped on that redirect.
I'll apply your patch.

The question is - is it getting dropped somewhere else as well, beacuse I saw the issue, but just have hard time catching it (even without using $wgOpenIDOnly).
Comment 13 Sergey Chernyshev 2009-12-07 23:47:58 UTC
OK, looks like I was able to nail it down to the session - if you just start the browser, then returnto gets dropped somewhere in the chain on first OpenID login, then on consequent OpenID logins it works fine.
Comment 14 Alexandre Emsenhuber [IAlex] 2009-12-20 14:59:07 UTC
"returntoquery" parameter added in r60239.
Comment 15 Craig Box 2010-04-19 15:55:37 UTC
Created attachment 7308 [details]
Fix for problem with redirect (only on first attempt to log in)

Finally got bothered enough to sit down with this one today.

The problem, as Sergei alluded to, is that you are storing information on the session before the session is initialized as far as MW is concerned.  Adding a startSession() before saving the return page onto the session fixes the problem - one-line patch attached.
Comment 16 Sergey Chernyshev 2010-04-21 15:12:41 UTC
Perfect, it nailed it!

Applied in r65395.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links