Last modified: 2013-11-15 10:21:16 UTC
I'll try to describe this reproducible problem, it's difficult to describe but perhaps someone of you has seen this problem also. When users have requested a temporary password through Special:PasswortReset and - come back to the wiki - and then click onto the Special:Login link (portlet) in order to get the password page, I noticed (the problem:) that often this portlet has a wrong value and after entering the temporary pw and the new password twice, the wiki shows again the Special:PasswordReset page instead of going to the Main page. Perhaps a new RequestContext should be set, but I do not know, how this can be done at that moment. When doing a passwort reset (enter the temporary password and twice a different, new password) on /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset the Create Account/Login portlet has incorrectly /index.php?title=Special:UserLogin&returnto=Special%3APasswordReset instead of /index.php?title=Special:UserLogin&returnto=Main+Page
Hello, I would like to solve this bug. As per my understanding, generally after the user login, the page is redirected back to the page user was originally on due to the parameter 'returnto' of the $request object (WebRequest). Since in this case, the user was on 'PasswordRequest' page, he would be redirected to the same page again. Hence in this case, we might need to explicitly set the parameter to the 'main-page'. Hence it would be a code addition somewhere in the PasswordReset page for setting the value of some parameter to 'main-page' which would reflect in $request['returnto'] Kindly suggest if I am on the right track and guide. Thanks, Aashish
(In reply to comment #1) > As per my understanding, generally after the user login, the page is redirected > back to the page user was originally on due to the parameter 'returnto' of the > $request object (WebRequest). > Since in this case, the user was on 'PasswordRequest' page, he would be > redirected to the same page again. Hence in this case, we might need to > explicitly set the parameter to the 'main-page'. Hence it would be a code > addition somewhere in the PasswordReset page for setting the value of some > parameter to 'main-page' which would reflect in $request['returnto'] > > Aashish I think, I need to give a detailed analysis. Allow me to use some "bold" words to point to the differences. There is _no_ problem for this case I: - you or someone else has triggered to have the password "reset" mail sent to you from the Special:PasswordReset page - you go to your mail client - you click on the link in your mail - the link goes to https://server/phase3/index.php/Main_Page - you come to the newly rendered Main page - where you now click onto login - enter your temporary password, and 2x the new one = Okay The problem is visible in this scenario case II: - you or someone else has triggered to have the password "reset" mail sent to you from the Special:PasswordReset page - (X) you LEAVE THIS browser page as it stands (saying something like "a temporary password has been successfully mailed to ...") - you goto to your mail - you DO NOT click on the link in your mail (the link goes to https://server/phase3/index.php/Main_Page) - you switch to your still-opened browser window with the unchanged page of step (X) - where you now click onto login link (THIS LINK HAS THE WRONG returnto https://server/phase3/index.php?title=Special:UserLogin&returnto=Special%3APasswordReset because the page was not rendered again, still stands at (X) ) - enter your temporary password, and 2x the new one Problem: now your are again at "Special:PasswordReset" , which is correct behaviour of the Wiki software, but not what a user wants.
Created attachment 9988 [details] changes to SpecialUserLogin to return to Main_Page after a password change Hello, Thanks for the detailed explanation. I reproduced the second scenario and was able to figure out the following solutions for it: 1. Modification of SpecialUserLogin to check if the returntitle is PasswordReset. If yes, make the returnto empty. The code snippet is: # Do not redirect back to PasswordReset (instead to the Main_Page) after a successful password change if( is_object( $returnToTitle ) && $returnToTitle->isSpecial( 'PasswordReset' ) ) { $this->mReturnTo = ''; $this->mReturnToQuery = ''; } In this case, the returnto is still set to PasswordReset in the url, but after Login submission, the returnto is made emptied. Similar solution exits for the UserLogout page. In the case of UserLogout, if I manually go to UserLogout and click on Login, the returnto is set to UserLogout. Hence after successful login, the user would be returned to Logout page, but similar code prevents it from going to Logout page. 2. Second solution is to modify the SkinTemplate to modify the login url itself. In the SkinTemplate, I can check the $wgRequest->getVal('returnto') and if it is set to PasswordReset, I can modify it to Main_Page. This would change the returnto in the $loginurl itself and would be used to return the user back to main page once the user has logged in. I am attaching a patch for the former, kindly give your review which solution is more suitable and if the code and the output seems fine. Thanks in advance. Regards, Aashish
I tried your patch, this appears to work as expected and described. great. fixed in r111270
