$_SESSION vars will not persist on pages other than login..?

[jdavidbakr]

Here's some code that I built to do what you're trying to do.  I actually set a cookie with the session_id in it, which allowed me to access the same session_id across multiple subdomains.  Here's the code:

 

if ($_COOKIE[kSessionName]) {
  session_id($_COOKIE[kSessionName]);
} else {
  session_id(md5(uniqid(rand())));
}
session_name(kSessionName);
session_start();
setcookie(kSessionName,session_id(),0,'/',kSiteBase);

 

kSessionName is the name of the session (i.e. PHPSESSID, I like to name this something a bit less generic but that's just me)

kSiteBase is the primary domain, i.e. if you're going from http://www.example.com/ to https://www.example.com to http://sub.example.com then kSiteBase would be example.com

 

What is actually happening here is I'm first checking the cookie for the session_id, and setting the session_id to that value if it exists.  If not, I'm making up a hash to use for the session_id.  Then I'm starting the session, and storing the session_id back in the cookie - which is accessible from all subdomains - for the next page call.

[BizLab]

Here's some code that I built to do what you're trying to do.  I actually set a cookie with the session_id in it, which allowed me to access the same session_id across multiple subdomains.  Here's the code:

 

if ($_COOKIE[kSessionName]) {
  session_id($_COOKIE[kSessionName]);
} else {
  session_id(md5(uniqid(rand())));
}
session_name(kSessionName);
session_start();
setcookie(kSessionName,session_id(),0,'/',kSiteBase);

 

kSessionName is the name of the session (i.e. PHPSESSID, I like to name this something a bit less generic but that's just me)

kSiteBase is the primary domain, i.e. if you're going from http://www.example.com/ to https://www.example.com to http://sub.example.com then kSiteBase would be example.com

 

What is actually happening here is I'm first checking the cookie for the session_id, and setting the session_id to that value if it exists.  If not, I'm making up a hash to use for the session_id.  Then I'm starting the session, and storing the session_id back in the cookie - which is accessible from all subdomains - for the next page call.

 

Great work Jon, i like this alot. I will mess with it today and see if i can get some things working! I will post the results later, but this is by far the best solution i have seen.

 

I realize that without cookies enabled, users will not be able to progress... I wonder if i can post a warning somewhere to let them know that...

 

if($test_cookie_fails){
   echo '<p>Your cookies are disabled! You must enable them to login.. blah blah</p>';
}

 

thanks alot man

[PFMaBiSmAd]

For the same reason that a session id cookie is not passed between http and https protocols, a browser will not pass regular cookies back and forth between http and https protocols either. It is not secure.

 

At the risk of repeating information - If you have something important enough that you are starting a session setting a cookie using a HTTPS connection, you must continue using a HTTPS connection to access that same session cookie data.

[jdavidbakr]

I realize that without cookies enabled, users will not be able to progress... I wonder if i can post a warning somewhere to let them know that...

 

if($test_cookie_fails){
   echo '<p>Your cookies are disabled! You must enable them to login.. blah blah</p>';
}

 

Without cookies, sessions won't work either.  Nothing wrong with alerting the user either way.

[jdavidbakr]

For the same reason that a session id cookie is not passed between http and https protocols, a browser will not pass regular cookies back and forth between http and https protocols either. It is not secure.

 

At the risk of repeating information - If you have something important enough that you are starting a session setting a cookie using a HTTPS connection, you must continue using a HTTPS connection to access that same session cookie data.

 

Are you sure?  I've never had an issue with a session or cookie not passing between http and https.

 

I just did a test:

 

<?
session_start();
if (!$_SESSION['value'])	{
  $_SESSION['value'] = rand();
}
echo $_SESSION['value'];
?>

 

Opening the page in http gives me a random number, refreshing the page displays the same number.  Opening the page in https also is giving me the same number.

[BizLab]

For the same reason that a session id cookie is not passed between http and https protocols, a browser will not pass regular cookies back and forth between http and https protocols either. It is not secure.

 

At the risk of repeating information - If you have something important enough that you are starting a session setting a cookie using a HTTPS connection, you must continue using a HTTPS connection to access that same session cookie data.

 

Are you sure?  I've never had an issue with a session or cookie not passing between http and https.

 

I just did a test:

 

<?
session_start();
if (!$_SESSION['value'])	{
  $_SESSION['value'] = rand();
}
echo $_SESSION['value'];
?>

 

Opening the page in http gives me a random number, refreshing the page displays the same number.  Opening the page in https also is giving me the same number.

 

Jon, i just replicated that test on a live site with an active SSL cert and it fails. I generate a new id on every refresh... even if i just refresh the https page

 

-- HOWEVER ---

while in the http protocol, the session var is held....

 

Why would my HTTPS pages not hold session variables without any transfer in protocol, without redirects, without anything really...

 

Any ideas peoples?

[PFMaBiSmAd]

All browsers (are supposed to) maintain separate caches for http and https cookies for security reasons. If you found a case where a cookie (session or otherwise) is being passed between protocols, you either have a browser that is insecure or you are actually passing the session id through the URL and not through a cookie.

[PFMaBiSmAd]

Why would my HTTPS pages not hold session variables without any transfer in protocol, without redirects, without anything really...

 

You either have an error in your code or you are switching the domain and/or path and the session id cookie parameters are not setup to cause the cookie to match the switch.

 

Post the URL's of the pages you are using (xxxxx out the domain portion if you don't want to post that information, but don't change any of the rest of the information in the URL's.)

 

Near the start of this thread, you were asked to put in three lines of code that set the display_startup_errors, display_errors, and error_reporting level so that php would point out problems it detects. Are you still using this for debugging?

 

It would take seeing the offending code. We cannot really tell you anything about why your code is or is not doing anything without seeing the actual code that exhibits the problem.

[BizLab]

Why would my HTTPS pages not hold session variables without any transfer in protocol, without redirects, without anything really...

 

You either have an error in your code or you are switching the domain and/or path and the session id cookie parameters are not setup to cause the cookie to match the switch.

 

Post the URL's of the pages you are using (xxxxx out the domain portion if you don't want to post that information, but don't change any of the rest of the information in the URL's.)

 

Near the start of this thread, you were asked to put in three lines of code that set the display_startup_errors, display_errors, and error_reporting level so that php would point out problems it detects. Are you still using this for debugging?

 

It would take seeing the offending code. We cannot really tell you anything about why your code is or is not doing anything without seeing the actual code that exhibits the problem.

 

I'm actually using the same test code from above:

<?php
// session passing test
session_start();
if (!$_SESSION['value']){
  $_SESSION['value'] = rand();
}
echo 'SESSION VALUE: '.$_SESSION['value'];
?>

 

That is literally the only code on the page

 

As far as the url passing, i am hitting a F5 refresh on the page - so the url is literally the same

 

https://www.domain.com/admin/office/session-var-test.php

 

or (if testing the http protocol)

http://www.domain.com/admin/office/session-var-test.php

[BizLab]

POSSIBLE PROGRESS HERE GUYS

 

So after some digging, i found a resource speaking of HTTP persistent connections. After reading about them here: <a href="http://en.wikipedia.org/wiki/HTTP_persistent_connection#Use_in_web_browsers">http://en.wikipedia.org/wiki/HTTP_persistent_connection#Use_in_web_browsers</a>

 

I check the server config. In the Apache2handler i have

Max Requests Per Child: 4000 - Keep Alive: off - Max Per Connection: 100

Timeouts Connection: 20 - Keep-Alive: 15

 

-- anything??

 

i have no idea at this point

[PFMaBiSmAd]

A persistent connection has nothing to do with the information a browser supplies with each http (or https) request it makes to the server using that connection.

[BizLab]

A persistent connection has nothing to do with the information a browser supplies with each http (or https) request it makes to the server using that connection.

 

I get that, what i'm saying is that maybe the server is dropping the connection on each refresh while in https?

[PFMaBiSmAd]

So, is this a correct statement - You went from having a login script that used a session under https that somewhat worked (i.e. you could return to the login page and you were still logged in) to not having sessions work under https? Doesn't that suggest it is not the connection but that the current code is not setting or getting the session id cookie.

 

You apparently skipped reading the following because the code you just posted does not contain the three lines of debugging code -

Near the start of this thread, you were asked to put in three lines of code that set the display_startup_errors, display_errors, and error_reporting level so that php would point out problems it detects. Are you still using this for debugging?

[jdavidbakr]

All browsers (are supposed to) maintain separate caches for http and https cookies for security reasons. If you found a case where a cookie (session or otherwise) is being passed between protocols, you either have a browser that is insecure or you are actually passing the session id through the URL and not through a cookie.

 

Hm, tell me what you see from these two pages:

 

http://rapidrain.com/session.php

 

https://rapidrain.com/session.php

 

I've tested Firefox and Safari on the Mac, and IE8 and Firefox on the PC, each browser gives me the same random number whether I'm in http or https.

 

That session.php script is exactly what I posted above.

[PFMaBiSmAd]

Hmmm. It does work. That contradicts available information (i.e. FF maintains separate cookie caches and does not pass cookies between protocols) and observed history (i.e. threads like this one where it does not work and threads where the only successful way of passing the session id would be to put it onto the end of the URL.)

 

I can tell you why it works, at least in your case. The 'secure' parameter (of either the session id cookie or a regular cookie) is off.

 

However, turning on the 'secure' parameter causes the session to only work under https and to not work at all under http. So, this alone does not explain the cases where you can have sessions that work under each protocol but don't pass between the protocols. You would need to 'dynamically' change the 'secure' parameter depending on the protocol used in the request for it to account for the observed operation. I suspect (but did not find any information either way) that this is something that specific web servers have done internally in the past.

[jdavidbakr]

Hmmm. It does work. That contradicts available information (i.e. FF maintains separate cookie caches and does not pass cookies between protocols) and observed history (i.e. threads like this one where it does not work and threads where the only successful way of passing the session id would be to put it onto the end of the URL.)

 

I can tell you why it works, at least in your case. The 'secure' parameter (of either the session id cookie or a regular cookie) is off.

 

However, turning on the 'secure' parameter causes the session to only work under https and to not work at all under http. So, this alone does not explain the cases where you can have sessions that work under each protocol but don't pass between the protocols. You would need to 'dynamically' change the 'secure' parameter depending on the protocol used in the request for it to account for the observed operation. I suspect (but did not find any information either way) that this is something that specific web servers have done internally in the past.

 

Interesting, I'm going to guess then that it's probably an option in PHP that is not enabled by default, but may be on in BizLab's case.  I have my own server, and I know that the php settings are set to the recommended defaults for PHP 5.1, all I've changed on that server is the error reporting options.  I don't, though, see where in php.ini it looks like this would be set.

[PFMaBiSmAd]

I did just find a change log entry for Apache where mod_rewrite added a way to allow the Cookie option to set the secure and HttpOnly flags. Unless proven otherwise, I'm going to stick with the idea that web servers internally set the 'secure' flag when a cookie is set over the https protocol and you cannot normally pass a cookie back and forth between the two protocols.

[BizLab]

So, is this a correct statement - You went from having a login script that used a session under https that somewhat worked (i.e. you could return to the login page and you were still logged in) to not having sessions work under https? Doesn't that suggest it is not the connection but that the current code is not setting or getting the session id cookie.

 

You apparently skipped reading the following because the code you just posted does not contain the three lines of debugging code -

Near the start of this thread, you were asked to put in three lines of code that set the display_startup_errors, display_errors, and error_reporting level so that php would point out problems it detects. Are you still using this for debugging?

 

How about this: this is the error reporting log

 

Warning: opendir() [function.opendir]: open_basedir restriction in effect. File(/var/lib/php/session) is not within the allowed path(s): (/var/www/vhosts/domain.com/httpdocs:/tmp) in /var/www/vhosts/domain.com/httpdocs/admin/office/index.php on line 84

 

Warning: opendir(/var/lib/php/session) [function.opendir]: failed to open dir: Operation not permitted in /var/www/vhosts/domain.com/httpdocs/admin/office/index.php on line 84

 

I am able to sign in and navigate the full https section of the site now. I am just wondering what that warning means... File permissions?? The session folder is read and writable by the web user... so i don't know what i am looking at here. i also don't know what the :/tmp is on the end of the first file path.

 

 

ALSO does anyone know what setting you are talking about on the server??

I would like to pass cookies from the https to the http user pages -  - there is no secure info in them anyway (user_id, first & last name, and some random system preferences) and the session id would be unsecured if my login wasn't SSL'ed  in the first place, so i am not compromising anything here. I just want to protect the username++password combo during login, thats all.

 

[PFMaBiSmAd]

Based on the error, line 84 of index.php is attempting to get a directory listing of the session data files, probably for an inefficient 'who is online' function. It is using the wrong path to the session data files.

 

The :tmp is because open_basedir is set to accept /var/www/vhosts/domain.com/httpdocs AND /tmp

 

The setting being discussed is session.cookie_secure It would be interesting to see what a phpinfo() statement shows for that setting, both through http and https.

[BizLab]

Based on the error, line 84 of index.php is attempting to get a directory listing of the session data files, probably for an inefficient 'who is online' function. It is using the wrong path to the session data files.

 

The :tmp is because open_basedir is set to accept /var/www/vhosts/domain.com/httpdocs AND /tmp

 

The setting being discussed is session.cookie_secure It would be interesting to see what a phpinfo() statement shows for that setting, both through http and https.

 

session.cookie_secure is set to  Off on both views

 

ok, so since you just shat all over my inefficient function, i'm assuming you have a much better way to easily display the number of users online..or better yet, actually logged in (other than marking a database field to 1 for logged in and 0 for logged out  - of course).

 

session.cookie_secure Off

[jdavidbakr]

ok, so since you just shat all over my inefficient function, i'm assuming you have a much better way to easily display the number of users online..or better yet, actually logged in (other than marking a database field to 1 for logged in and 0 for logged out  - of course).

 

Maybe store a field in the database "user_login_timeout" and set it to +5 minutes every time that user loads a page.  Then run a query on that table to look for timeouts in the future, that would give you your list.

 

Looking at the session files wouldn't really be useful, especially if your garbage collection on those session files is leaving them for very long.  If you've got a user who walks away without logging out (I'm assuming you're just destroying the session when they log out, but they may just close the browser), do you want to keep them marked as being logged in until the PHP garbage collection cleans up their session file?

[PFMaBiSmAd]

For your https session problem, when you browse to a https page, look in your browser's 'page info' section (assuming you are using FireFox) and tell us what the PHPSESSID cookie has for a Send For: value.

[BizLab]

For your https session problem, when you browse to a https page, look in your browser's 'page info' section (assuming you are using FireFox) and tell us what the PHPSESSID cookie has for a Send For: value.

 

it says "Send For: Any type of connection"

 

but i did notice that the PHPSESSID cookie is the only one with the entire www.domain.com... all other cookies are assigned to .domain.com

 

would that affect anything??

 

[BizLab]

For your https session problem, when you browse to a https page, look in your browser's 'page info' section (assuming you are using FireFox) and tell us what the PHPSESSID cookie has for a Send For: value.

 

Here are two more interesting errors

Warning: Unknown: open(/var/lib/php/session/sess_v2p116uh63sur11ts0toh31d92, O_RDWR) failed: Permission denied (13) in Unknown on line 0

 

Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/session) in Unknown on line 0

 

I think this is a group permission issue. I looked at my permissions and it looks like i have a rw for the owner only. I am trying to add the rw permission to the group BUT every time i type the command and check the file (ls -l) the permissions are not changed!! !

 

i'm using puTTY and typing (as the ROOT user):

chmod g+rw /var/lib/php/session

 

I'm pretty sure this is why my test of Jon's code failed. It explicitly states "permission denied" and the group in the session file has no access.

 

any ideas as to why the system will not allow me to add permissions??

 

[jdavidbakr]

Is this your own server?  If so, what flavor of Linux are you running?  Did you install apache/php from a repository for your distro or compile it yourself?  Almost feels like an SELinux issue.