Sessions for logging in broke when I switched to SSL HTTPS

[blueheronbeauty]

Hello I'm needing some help. Switched from http to https and now my Sessions are broken. I have a meeting soon with the big boss, and am at my wits end this morning.. 

 

Customer uses iPage for hosting.  Variable names have been changed to protect the innocent.

 

NOTE: session worked before switching to SSL, to log a person in, and keep them logged in as they surfed the site... Only I logged in, for development purpose, no public users ever did.

 

OK..

EXAMPLE  pre-SSL:

I go to site HTTP://foo..., I see a session id initialized in my cookies,  example: "a56h84gfg21908d788oe6gg5h99"

logging in took you from http://www.foo.com/login/ to  http://www.foo.com/userdashboard/  by checking user/pass, setting session variables and then using a redirect(url.'userdashboard') line

and session variables were updated like

$_Session[iamloggedin]=1;
$_Session[userdetails][userid]=345

 

etc;

and cookie session id was still "a56h84gfg21908d788oe6gg5h99" because everything looks great.

 

EXAMPLE post-SSL:

Now that https is working (site loads ok at least)

I go to site, I see this session id initialized in my cookies, therefore it is writing the initial session cookie ok - example: "c10ac91fd2c721908d788oeff305bc2"

I log in, do a dump(); to see what happened to session *right after I log in*, and sure enough 

$_Session[iamloggedin]=1;,
$_Session[userdetails][userid]=345;

 

is there ok

 

Take dump () out and allow page to forward to next page "https://www.foo.com/userdashboard/"   * which was successful before https*  

and now session cookie is still "c10ac91fd2c721908d788oeff305bc2"   (it did not generate a new cookie id)

but none of my custom user session variables exist. The dumped session after the redirect  which worked fine before, is now merely what you see when you visit "HTTPS://www.foo.com" no custom $_Session vars there, it lost them.

 

----

 

How domain is now loaded: using htacces file,  I added this alone: could this be problem?

RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}:443%{REQUEST_URI}

 

----

This is the php.info  -- the only thing I had changed here for https was   "session.cookie_secure On On"

PHP.ini settings related to session:

Session Support enabled
Registered save handlers files user
Registered serializer handlers php_serialize php php_binary wddx

Directive Local Value Master Value
session.auto_start Off Off
session.cache_expire 180 180
session.cache_limiter nocache nocache
session.cookie_domain no value no value
session.cookie_httponly Off Off
session.cookie_lifetime 0 0
session.cookie_path / /
session.cookie_secure On On
session.entropy_file /dev/urandom /dev/urandom
session.entropy_length 0 0
session.gc_divisor 1000 1000
session.gc_maxlifetime 1440 1440
session.gc_probability 1 1
session.hash_bits_per_character 4 4
session.hash_function 0 0
session.name PHPSESSID PHPSESSID
session.referer_check no value no value
session.save_handler files files
session.save_path 4;/hermes/phpsessions 4;/hermes/phpsessions
session.serialize_handler php php
session.upload_progress.cleanup On On
session.upload_progress.enabled On On
session.upload_progress.freq 1% 1%
session.upload_progress.min_freq 1 1
session.upload_progress.name PHP_SESSION_UPLOAD_PROGRESS PHP_SESSION_UPLOAD_PROGRESS
session.upload_progress.prefix upload_progress_ upload_progress_
session.use_cookies On On
session.use_only_cookies On On
session.use_strict_mode Off Off
session.use_trans_sid 0 0

 

----

 

Again, this worked great before https was involved. So, why could this be happening, session being written on server not retrievable for some reason - it has the cookie id but maybe nothing was saved on server?  Is my htaccess file wrong?  Some other setting in php.ini that is wrong?  Anyone have any ideas? This is iPage server, so shared hosting, so I do not have ability to see as much of server as a dedicated server.. 

Thank you for your generous help!

Wits End is not a nice place to visit and I don't wanna live here!

[Jacques1]

The save path looks odd. Are you sure that the session is actually persisted to disk?

 

Also check the PHP error log.

Edited January 5, 2017 by Jacques1

[blueheronbeauty]

The save path looks odd. Are you sure that the session is actually persisted to disk?

 

Also check the PHP error log.

 

Thanks for your reply..

It is the default path iPage sets, and has been unchanged.

Sessions worked previously before https, therefore were persistent then..

PHP error logs are empty. 

Maybe I try to set a custom path? I was hoping not to add more complexity. Thought their default should work since it worked before.

[requinix]

The save path looks odd. Are you sure that the session is actually persisted to disk?

The N;path syntax for the files handler means to spread the session files N directories deep, so 123456 will be at /hermes/phpsessions/1/2/3/4/123456.

 

Can you look at the session file itself to make sure it has data at all points in the process? It could be encrypted, but even if you can still tell whether there's stuff in there and whether it changes.

[blueheronbeauty]

Can you look at the session file itself to make sure it has data at all points in the process? It could be encrypted, but even if you can still tell whether there's stuff in there and whether it changes.

Looks like I do not have access via iPage to see that info.

I only have access to visitor log files and php error log file.

[blueheronbeauty]

I thought perhaps the redirect(url.'userdashboard') could be the issue, since in the past I did see people talking about this hurting session in certain browsers, however those forums stated the issue was fixed in php 3 or 4 or something way back when. (and then why did everything work with http://...) we are using php 5.5

 

I tested this: I exited my login script just after setting the custom session variables $_Session[userdetails][userid]=345..., and simply typed in another page of the site to see if my custom session vars were still there, and they were not. So it seems a persistency issue? Perhaps I just have to contact iPage (gah).  I was hoping to avoid that.

[blueheronbeauty]

Since I have access to edit the php.ini I edited the session.save-path setting to direct it to cgi-bin/tmp, using the suggested path info that their knowledgebase indicates -- and their system replaces it automatically back to "4;/hermes/phpsessions"   so I don't think they are allowing that change presently. 

[blueheronbeauty]

Changed htaccess to 

RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]

and it made no difference, so I guess my only recourse is to contact them.

Thanks for trying, guys.

[blueheronbeauty]

They are no help. I might lose my job because I can't launch this new customer/employee log-in module. This sucks so bad.  I went through their customer service and showed via screenshot and web page example what is happening, and that I can not go any further in diagnoses because obviously they do not allow me to edit the place where the session variables are stored and their response was basically: "We don't allow you to change where session variables are stored. Have a nice day. Ticket closed." They avoided my question by agreeing with my comment. :|

[blueheronbeauty]

OK running the scenario through my head - our Session was able to be stored ok before SSL.. They installed SSL certificate manually because there was some issue with their "click here to install your newly bought certificate" -it wasn't working.... So session storage was WORKING when we used http:// and was WORKING when they had stalled the certificate, but I was still for a few days using HTTP://.... we hadn't switched over and we were still using http:// for a few days till I could get around to making the change.

 

So then I change my htaccess file to load the page https:// and change pages that need css to load css from https:// so then the site loads ok...

So if the Session was being stored ok using http://, even after they installed the cert... doesn't that mean it has to be how the page is SENDING the session data via https? https:// page is not able to write a session var to server.. 

 

So is the problem in MY lap, or iPage's lap? Seems like mine..?

 

Here's code that stores session: You guys see anything glaringly wrong here?

<?php
class Session{
	private $sess_save_path;
	static private $obj_instance;

	private function __construct(){}

	static function get_instance(){
		if( !isset(self::$obj_instance) ){
			self::$obj_instance = new self;
			session_set_save_handler(array(self::$obj_instance,"open"), array(self::$obj_instance,"close"), array(self::$obj_instance,"read"), array(self::$obj_instance,"write"), array(self::$obj_instance,"destroy"), array(self::$obj_instance,"gc") );
			session_start();
		}
		return self::$obj_instance;
	}

	function __set( $name, $value ){
		$_SESSION[$name] = $value;
	}

	function __get( $name ){
		return isset( $_SESSION[$name] ) ? $_SESSION[$name] : null;
	}

	function open($save_path, $session_name){
		$this->sess_save_path = $save_path;
		return true;
	}

	function close(){
		return true;
	}

	function read($id){
		$sess_file = $this->sess_save_path . "/sess_$id";
		if( file_exists($sess_file) )
			return file_get_contents($sess_file);
	}

	function write($id, $sess_data){
		$sess_file = $this->sess_save_path . "/sess_$id";   
		return file_put_contents( $sess_file, $sess_data );   
	}

	function destroy($id){
		$sess_file = $this->sess_save_path . "/sess_$id";
		if(file_exists($sess_file))
			return unlink($sess_file);
	}

	function gc($maxlifetime){
		foreach (glob("$this->sess_save_path/sess_*") as $filename) {
			if ( file_exists($filename) && filemtime($filename) + $maxlifetime < time()){}
				//unlink($filename);
		}
		return true;
	}
	
	
	
		
		
}
// -- end
?>

[Jacques1]

You should have told us a bit earlier that you're using a custom session mechanism.

 

In that case I suggest you create a minimal test script without the class using nothing but standard PHP sessions:

<?php

session_start();

echo 'Session ID: '.session_id().'<br>';

echo 'Cookies received:<br>';
var_dump($_COOKIE);
echo '<br>';

echo 'Session:<br>';
var_dump($_SESSION);
echo '<br>';

$_SESSION['foo'] = 'bar';

Clear your cookies and visit the page. Both the cookie array and session data should be empty. Check your browser if you've received the session cookie. Then visit the page again. Both the cookie array and the session should now be filled.

 

Also try different browsers. And temporarily disable session.cookie_secure.

 

In any case, stop insisting that it's a HTTPS problem. That might be the cause, but it could also be something entirely different which happened during the update. Since you have no server access to actually find out, you should be very careful with assumptions.

 

The session class definitely has not been implemented correctly. It doesn't even lock the files, which means concurrent accesses will trample each other. I'm not saying this is the reason for your current problem, but it's something you need to be aware of and which has to be fixed. What is the purpose of the class, anyway?

Edited January 7, 2017 by Jacques1

[blueheronbeauty]

You should have told us a bit earlier that you're using a custom session mechanism.

 

In that case I suggest you create a minimal test script without the class using nothing but standard PHP sessions:

<?php

session_start();

echo 'Session ID: '.session_id().'<br>';

echo 'Cookies received:<br>';
var_dump($_COOKIE);
echo '<br>';

echo 'Session:<br>';
var_dump($_SESSION);
echo '<br>';

$_SESSION['foo'] = 'bar';

Clear your cookies and visit the page. Both the cookie array and session data should be empty. Check your browser if you've received the session cookie. Then visit the page again. Both the cookie array and the session should now be filled.

 

Also try different browsers. And temporarily disable session.cookie_secure.

 

In any case, stop insisting that it's a HTTPS problem. That might be the cause, but it could also be something entirely different which happened during the update. Since you have no server access to actually find out, you should be very careful with assumptions.

 

The session class definitely has not been implemented correctly. It doesn't even lock the files, which means concurrent accesses will trample each other. I'm not saying this is the reason for your current problem, but it's something you need to be aware of and which has to be fixed. What is the purpose of the class, anyway?

 

OK thank you, this test works fine.

I'm using an MVC package which was used by a big development house on a previous job where I worked after they had already created a site with full login capabilites. 

I liked how it worked, so I got it from github and have been implementing it to my new job.. 

Sorry I did not post that class before... I think I'm loopy from working late nights for too long...

I didn't previously see the lack of lock etc when I surfed this package to make sure it looked good.

I appreciate the direction, I'll use this info to fix these issues and edit my code / not use this class. 

[Jacques1]

I think I've found the problem: The open() function of the session handler receives your literal path parameter “4;/hermes/phpsessions”. It's then up to the class to resolve the subdirectory depth stuff. Since it doesn't do that and just appends the file name to the path, you end up trying to write files like “4;/hermes/phpsessions/sess_1234”, which is of course nonsense. The class cannot handle empty path settings either (which should be interpreted as: use the default temporary folder).

 

So my guess is that the server admin has at some point changed the session path from a physical directory to the “4;...” setting, and that's when the class broke down.

 

Long story short: Get rid the class or turn it into a simple wrapper for the standard session mechanism. The class right now is hopelessly broken and doesn't seem to offer any benefit at all; reimplementing it correctly will waste a lot of time, and I don't think anybody is willing to accept delays for that.

[blueheronbeauty]

Thank you! I got rid of the class. Such a simple solution. The app is launched and training has begun! Everyone is happy. You guys rock!