SMF Development > Fixed or Bogus Bugs

Quick login does not remember last page properly

<< < (2/3) > >>

_Jojo_:
Well, to me this happens quite frequently and it's also kind of annoying when it happens. I haven't looked into the code but it would seem to be that some kind of flag is set when visiting member profiles and is not unset when visiting another page instead.

Either way, I'd say this is not a bogus bug, nor is it fixed, so it should be moved back again.

Joker™:
It has to something with "$_SESSION['login_url']" and "$_SESSION['old_url']".

I'll debug this once I get back to my PC.

Joshua Dickerson:
Joker, any luck?

Joker™:
Joshua, got a few mins for debugging :P.

Here is some data populated by the script:

1. Click on Profile as guest:
Login URL -- Nothing
Old URL: http://localhost/smf2/index.php


2. Come back to main page (Seems fine upto here)
Login URL -- http://localhost/smf2/index.php?action=profile;u=1
Old URL: http://localhost/smf2/index.php?action=profile;u=1


3. Go to some topic (See below, url weirdness starts here)
Login URL -- http://localhost/smf2/index.php?action=profile;u=1
Old URL: http://localhost/smf2/index.php


Now if someone is going to make a login is he going to be redirected according to 'login_url' as per this code in LogInOut.php


--- Code: ---// Some whitelisting for login_url...
if (empty($_SESSION['login_url']))
redirectexit();
else
{
// Best not to clutter the session data too much...
$temp = $_SESSION['login_url'];
unset($_SESSION['login_url']);

redirectexit($temp);
}
--- End code ---


My suggestion would be to re-factorize the 'login_url' variable and place the current link in it, as even the 'old_url' variable is running one step behind the actual query string.

emanuele:
The problem here is that when you arrive at the login page (through profile) $_SESSION['login_url'] is set, then the quick login doesn't pass through the function Login and 'old_url' doesn't overwrite 'login_url', so you are redirected to Login2 with 'login_url' set (when accessing the login page viewing the profile) to the wrong address.

The only reliable way to overcome this problem I can think it let Login2 know that we are coming from the quicklogin (i.e. add a ";quicklogin" to the form action url). Then we have to re-set the 'login_url' in Login2:

--- Code: (find) --- if (empty($_SESSION['login_url']) && isset($_SESSION['old_url']) && strpos($_SESSION['old_url'], 'dlattach') === false && preg_match('~(board|topic)[=,]~', $_SESSION['old_url']) != 0)
--- End code ---


--- Code: (replace with) --- if ((empty($_SESSION['login_url']) && isset($_SESSION['old_url']) && strpos($_SESSION['old_url'], 'dlattach') === false && preg_match('~(board|topic)[=,]~', $_SESSION['old_url']) != 0) || (isset($_GET['quicklogin']) && isset($_SESSION['old_url']) && strpos($_SESSION['old_url'], 'login') === false))
--- End code ---

The strpos($_SESSION['old_url'], 'login') === false will prevent the user from being redirected to the login page in the case of the (non particularly clever) action of logging in from the quick-login at the login page.

Navigation

[0] Message Index

[#] Next page

[*] Previous page