ashishmittal.mail wrote:

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.

ashishmittal.mail wrote:

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

Attached:

I tried your patch, this appears to work as expected and described.

great. fixed in r111270