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!

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.

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 ?>

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. :|

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.

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.

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.

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.

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.

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!