Loss of SESSION in Login2()?

[mvandemar]

Ok, after trying several variations of suggestions that used to work in earlier versions, having to do with returning the user to a non-smf page after logging in/out, I think I have narrowed down the problem.

In LogInOut.php, if you add this line at the beginning of Login2():

Code Select Expand


function Login2()
{
global $txt, $db_prefix, $scripturl, $user_info, $user_settings;
global $cookiename, $maintenance, $ID_MEMBER, $modSettings, $context, $sc;
global $sourcedir;

$_SESSION['login_url'] = 'http://www.somesite.com/custompage.php';


You will then get the redirect after they log in. However, if you attempt to actually set the page that you want to return to using a session variable, even if it is one that SMF doesn't use (and therefore shouldn't be clearing it accidentally), it fails, because the session variable comes up empty:

Code Select Expand


function Login2()
{
global $txt, $db_prefix, $scripturl, $user_info, $user_settings;
global $cookiename, $maintenance, $ID_MEMBER, $modSettings, $context, $sc;
global $sourcedir;

$_SESSION['login_url'] = '$_SESSION['root_url']';


This is not true if you are using the same method with Logout() (which actually works just fine if you set $_SESSION['logout_url'] with no modifications to the code). So....

1) Is there a problem setting session variables in smf when the user is not logged in?
2) Is the session variable being destroyed somewhere along the line in the login process?
3) If either of those are true, what would be the workaround?

Thanks.

-Michael

PS: Currently none of the suggestions that used to work in this Tips thread are valid because of this, aside from hardcoding the URL:

http://www.simplemachines.org/community/index.php?topic=27475.0

[mvandemar]

Actually, I just realized it's not #1, because if I drop a die($_SESSION['login_url']); in place there, it shows it... which means that at least the first pass through Login2() the session does exist. Therefore something must be destroying the session in a subsequent pass.

Any ideas?

-Michael

[mvandemar]

Would this qualify as a bug? Did I post in the wrong forum? Or is it intentional?

I've seen it mentioned a few times, with no currently working resolution.

Thx.

-Michael

[SleePy]

Code Select Expand

$_SESSION['login_url'] = '$_SESSION['root_url']';

should be

Code Select Expand

$_SESSION['login_url'] = $_SESSION['root_url'];

[mvandemar]

Technically you are right, it should indeed... but it doesn't matter, since the session appears to be getting destroyed by that point anyways. By dropping this code at the beginning of Login2(), you can see that by the last pass through the variable is empty either way:

Code Select Expand


if(!isset($_SESSION['root_url'])){
    die("nothing to see, move along...");
}


Works fine going in, but the function is called several times with varying parameters, and by the last time through, when you are in fact already logged in, any session variables set appear to be empty.

I actually am using a separate 30 minute cookie to track the return page now, since it was holding me up on my dev. It does mean that the Tips thread is invalid for logging in though as written (although logging out retains the session):

http://www.simplemachines.org/community/index.php?topic=27475.0

-Michael

[mvandemar]

Btw, if anyone with mod powers reads this and has a sec, could you please edit the title to reflect the actual function I meant? Sorry for the typo. 

Thanks!

-Michael

[SleePy]

I had the same issue on my site, but yet on my test site on the same server it worked :| I don't know why either.
I finally gave up on my companies site and did a base64 encode and added it into the url and hacked my login script to work with that (While making sure the url was on my server allowed list).

Is root_url being passed? Just not the login_url?

[mvandemar]

Is root_url being passed? Just not the login_url?

No, root_url was my attempt to try the same thing with a non-smf variable, to see if it was specific variables that were losing their values (in which case I would just use that as a buffer), or all session variables (which seems to be the case).

I just couldn't pin down exactly where it was happening. I just know that by the time the pass through Login2() happens that variable is gone, you are in fact already logged in, which leads me to believe that it is the second to last pass where it gets destroyed. Maybe somewhere in redirectexit()...?

This block in Login2(), where it deletes the guest record after login, makes me think that it might actually be intentional:

Code Select Expand


// Get rid of the online entry for that old guest....
db_query("
DELETE FROM {$db_prefix}log_online
WHERE session = 'ip$user_info[ip]'
LIMIT 1", __FILE__, __LINE__);
$_SESSION['log_time'] = 0;


But at that point the session still exists, so not sure.

-Michael

[SleePy]

The session url isn't passed by reference into the redirectexit function. So this would not be the case.

What needs done is just sending output of the session variable all the way to the end and have redirextexit before it redirects you allowing you to see the output.

[mvandemar]

Except that it has to redirect to get to that point... it redirects 2-3 times before losing the variable, calling the same functions each time.

And the session wouldn't have to be passed by reference to be affected, by the very nature of session variables. They are cookies that persist from page to page, not to mention function to function. They are superglobals.

-Michael

[SleePy]

How are you calling it right now? I will try to emulate it tomorrow on a 2.0 forum and see what i can get to happen.

[mvandemar]

I am posting the form to:

index.php?action=login2

This invokes Login2() in LogInOut.php, which makes calls to functions in Subs.php (possibly more). At some point Login2() calls redirectexit(), which redirects to:

index.php?action=login2;sa=check;member=1

Which again invokes Login2(), at the beginning of which:

a) you are indeed logged in, and
b) the session variables set at the beginning of (and during) this process are empty.

However, the session does exist with these values (as determined by print_r($_SESSION)):

Code Select Expand


Array
(
    [rand_code] => df0bef13d8334b18d3981275bcab7f14
    [ID_MSG_LAST_VISIT] => 1
    [log_time] => 1197697092
    [timeOnlineUpdated] => 1197697092
)


-Michael

[SleePy]

your not using ssi_login?

[mvandemar]

No, I am using smf_api.php to load the user data and determine whether or not it is a guest or a logged in user, and if logged in who they are, but so far that's all.

As far as I can tell though, the only thing ssi_login does is generate the form and set the session variable for you.

-Michael

[SleePy]

Yea thats all it does..

I am just about to run off to bed tonight from a long day but I will try to see if I can squeeze in some debugging of this. I would want to know why as well.

[mvandemar]

Yea thats all it does..

I am just about to run off to bed tonight from a long day but I will try to see if I can squeeze in some debugging of this. I would want to know why as well.

SleePy, you ever get a chance to look into this?

-Michael

[SleePy]

No. I forgot to check on this.. Again I am running running off to bed. But this time I will leave the email notification marked unread so I see it tomorrow when I check my email.

[SleePy]

Hmm.

Ok I tracked it down. It seems to exist all the way through Login2. But it is dropped after it redirects you to the check page.

I will submit this as a bug (Edit, for team reference this bug is 1183).
A work around for this is to open LogInOut.php and find:

Code Select Expand

// Just log you back out if it's in maintenance mode and you AREN'T an admin.
if (empty($maintenance) || allowedTo('admin_forum'))
redirectexit('action=login2;sa=check;member=' . $user_info['id'], $context['server']['needs_login_fix']);
And replace that with this:

Code Select Expand

// Just log you back out if it's in maintenance mode and you AREN'T an admin.
if (empty($maintenance) || allowedTo('admin_forum') && isset($_SESSION['login_url']))
redirectexit($_SESSION['login_url'], $context['server']['needs_login_fix']);
elseif (empty($maintenance) || allowedTo('admin_forum'))
redirectexit('action=login2;sa=check;member=' . $user_info['id'], $context['server']['needs_login_fix']);

Which basically does another check and avoids the login check if it finds the session url. I don't suggest avoiding the login check though as it ensures the user is logged in.

[mvandemar]

Which basically does another check and avoids the login check if it finds the session url. I don't suggest avoiding the login check though as it ensures the user is logged in.

Yeah, using a separate non-session cookie to hold the url seems like a better solution for now, that way nothing is bypassed. Would still be nice to know why the session is destroyed on login though.

-Michael

[SleePy]

I believe it is apart of a 1.1.3 fix (that was done to 2.0 as well) which destroys the old session and creates a new one. Though the odd part is that the session data is held in another variable until it is set again :|