I made a website that has an integrated shopping cart. Of course, I use a lot of session variables to do this. When I uploaded the site to inmotion hosting and made it an SSL connection, my session variables stopped transferring over? I have no idea why. I think part of it is because the sites are originally HTTP, then they are being forced to change to https, thus losing the session?
Any help would be amazing!
Ok I have tried changing the cookie domain and the cookie secure in the php.ini files but neither has helped. Please help!
Cookies have a secure flag on them which means that they can't be used on http sites. At HTTP connection, when you session_start(), PHP creates a new session id, which replaces the previous session id.
I believe you can unset that with session.cookie_secure = 1 in php.ini
Related
I recently built a Content Management System, and I'm using session variables throughout my code. However, I just switched over to HTTPS, and now it appears the session variables aren't working.
I've done a lot of research, but unfortunately I haven't found a solution to this problem yet. I'm thinking there has to be a setting in the "php.ini", or the IIS Manager (I'm currently using IIS 7.5) that I'm not seeing.
I found that in ISS Manager, under ASP -> Session Properties -> New ID On Secure Connection defaults to True - I can definitely see that being a problem if it's doing the same thing somewhere with PHP, but I can't find it if that's an option.
I'm initializing the session_start(); at the very beginning of the document (nothing comes before it), and it works fine over HTTP, just not HTTPS. Additionally, I've updated the base_url to include the https:// on any redirects, so it's not going from HTTP to HTTPS, it's strictly going over HTTPS.
Thanks in advance for any suggestions of where I might look.
I have a homebrew CMS installed on two different web servers. Each maintain the same code. I have had a really annoying problem when I try passing $_SESSION variables between different domains.
My CMS is on domain1.com. The website it is controlling is on domain2.com. My system passes all the session variables for the login information from domain1.com to domain2.com via a url link (domain1.com has a link like this: http://domain2.com?sessionId=1gh...)(sessionId is generated by session_id()). domain2.com retrieves the session id and does session_id($_GET['sessionId']) to set the session and grab the variables. It then proceeds to show a bar at the top with admin features.
This system works well on one of my hosts, as well as my localhost. But I recently transferred to a different host and installed my CMS with the same code with success. Everything works except for this feature. When I click on the link and try to set the session_id, the session_id changes, but the $_SESSION variables are removed. When I return to my CMS, I have to relogin. Somehow on this host, changing the session_id deletes the $_SESSION variables.
I have never liked session variables and I would not use them if I were to start again (I would probably use plain cookies). But I really need to figure this out. The host that it works on is Bluehost, with both domains hosted by Bluehost. The host that it does not work on is [EDIT]ByteHost, and the domain registrar is Godaddy.
Here is some example code from domain2.com:
...
if ( $_GET['sessionId'] )
{
session_id($_GET['sessionId']);
}
session_start();
echo session_id(); // returns the proper sessionId passed through the url
print_r($_SESSION); // does not work. returns array()
...
I can guarantee that the $_SESSION variables existed before, because I was still logged into my CMS.
Any ideas why session variables work on 1 host, but not on another?
I tried replacing the php.ini file with the working host one. Problem was still there.
Thank you for your time!
UPDATE
I ended up removing this from my CMS. Now, I just pass the login details over the url and it logs the person in. It works a lot cleaner.
Here are some reasons why this may not be working:
different physical server
different account for each domain (even if it's the same physical server)
different apache/php daemon for the domains (some shared hosting sites will create a separate directory for each domain, and then restrict apache from sharing information between domains. This will also have the effect of preventing session information from being passed. Think about it - do you want someone else's domain on the same hosting provider to have access to YOUR client's session info?)
configuration (apache or php), or .htaccess rules
Here is what I will recommend: stop doing this. This is a great opportunity to fix a very serious security flaw in your code. By the time you diagnose it with the hosting provider, you could probably just rewrite everything you need using HTML5 storage or secure cookies.
My guess is that the hosting provider is smart enough to protect session information form being stolen from another domain. But in either case, I strongly recommend you change the code so that it does not need to steal session information from another domain.
To have a session on multiple domains you would need to have the session id passed in the url instead of the sessions cookie as cookies only work on a single domain basis.
Using subdomains would solve the problem if they're not separate customers a.domain.com and b.domain.com
I would like to have my session work in my website when using www. AND when not using it.
I've read this thread:
PHP cookie problem - www or without www
And this would work, but I'm not creating cookies here, but sessions. How would I solve this? Also note that I don't know on which domain my scripts will run, so hardcoding the domain is not an option.
Is there a way to do this?
Thank you
EDIT:
I'm forcing that session ID's should be stored in cookies, so only this applies.
Use session_set_cookie_params function before calling session_start, it allows you to set the session domain and other things, set the domain to your domain prefixed with a . to make the session available to subdomains as well.
You can reflect php.ini for this. Add this in php.ini so that your session cookie will be saved at the place to be accessible with or without www
session.cookie_domain = .example.com
You can also try an alternate to do this
ini_set("session.cookie_domain", ".example.com");
And you can get the host name using $_SERVER['HTTP_HOST'] variable.
PHP uses cookies for the session id, so thats really the same problem (and solution). Have a look at the session configuration.
http://php.net/manual/en/session.configuration.php
Using the correct hostname across all requests is important for sessions. However, if you are going to be accessing cookies across multiple subdomains then you can specify the domain parameter with a prepended period. I.e.,
.example.com
I've experienced this problem with my cookies and your link in your post is great solving that.
So far, I'v never experienced difficulties with Sessions. It's independent from domain or sub domains, they are stored on the server-side.
You can Set in a config file a constant parameter DOMAIN_NAME, or in the DB, in prevision for your cookies, and then modify it only once.
I'm having some sessions problems after my ISP moved my site to a new server, supposedly setup the same. The problem appears to be browser-specific as well, which I don't quite understand.
First, my site uses sessions to login, this has been broken since they moved the site.
My ISP has set up a test page. When I hit this page in IE 6 (where it sets some session vars) and then hit the "header redirect" button, sessions seem to work fine. If I try it in Firefox/Opera, I get a new session id on the redirected page. My ISP reports sessions are working for IE as well, though I imagine they're using IE7 or perhaps even 8.
Everything was working fine on my site before my ISP moved it and while they've been very helpful in responding, they're at a loss as to why it's broken. A couple of other of my sites with them were broken along with the move, but they have been resolved by server tweaks...Does anyone have any ideas what's going on?
You're redirecting from "launchcomplex.com" to "www.launchcomplex.com"
If you set session.cookie_domain it should work - see session_set_cookie_params()
Cookie domain, for example 'www.php.net'. To make cookies visible on all subdomains then the domain must be prefixed with a dot like '.php.net'.
When they moved servers, did they move to a clustered configuration? Meaning when I hit your web page, am I always requesting content from the same physical server, or could be be any of a cluster of servers?
If the latter, that is your problem. Sessions are by default file-based, and thus are not scalable to multiple servers.
One solution is to use session_set_save_handler() to write your own session manager. Usually you would use a database to read/write session data using this method.
I have a login screen that I force to be ssl, so like this:
https://www.foobar.com/login
then after they login, they get moved to the homepage:
https://www.foobar.com/dashbaord
However, I want to move people off of SSL once logged in (to save CPU), so just after checking that they are in fact logged in on https://www.foobar.com/dashbaord I move them to
http://www.foobar.com/dashbaord
Well this always seems to wipe out the session variables, because when the page runs again, it confirms they are logged in (as all pages do) and session appears not to exist, so it moves them to the login screen.
Oddness/findings:
List item
The second login always works, and happily gets me to http://www.foobar.com/dashbaord
It successfully creates a cookie the first login
If I login twice, then logout, and login again, I don't need two logins (I seem to have traced this to the fact that the cookie exists). If I delete the cookie, I'm back to two logins.
After the second login, I can move from non-ssl from ssl and the session persists.
On the first login, the move to the non-ssl site wipes out the session entirely, manually moving back to the ssl site still forces me to login again.
The second login using the exact same mechanism as the first, over ssl
What I tried:
Playing with Cake's settings for security.level and session.checkagent - nothing
Having cake store the sessions in db (as opposed to file system) - nothing
Testing in FF, IE, Chrome on an XP machine.
So I feel like this is something related to the cookie being created but not being read.
Environment:
1. Debian
2. Apache 2
3. Mysql 4
4. PHP 5
5. CakePHP
6. Sessions are being saved PHP default, as files
I figured this out. Cake was switching the session.cookie_secure ini value on-the-fly while under SSL connections automatically, So the cookie being created was a secure cookie, which the second page wouldn't recognize.
Solution, comment out /cake/lib/session.php line 420 ish:
ini_set('session.cookie_secure', 1);
(Just search for that to find it, as I'm sure the line # will change as releases come out.)
While the accepted answer meets the OP's desire to "move people off of SSL once logged in" - it's horribly insecure in that it exposes the user session to hijacking (See Firesheep for an easy exploit).
A better compromise between the default behavior of CakePHP (which requires all pages to be served SSL after a user authenticates over SSL) and the accepted answer (which serves all authenticated pages unencrypted and exposes the authenticated cookie) is to serve pages encrypted over SSL if and only if they require authentication.
An easy way to accomplish this is to maintain two session cookies - one that is served secure and holds the authentication information and another which is served insecure. A simple implementation to support such a dual-session approach will use a session_handler to override the session.name like so:
if (env('HTTPS')) {
ini_set('session.name', Configure::read('Session.cookie').'-SECURE');
}else{
ini_set('session.name', Configure::read('Session.cookie'));
}
One item to keep in mind with this approach is that to link from a non-SSL page directly to a page that requires authentication will require you to explicitly link using https - since you'll need to send the session cookie containing the authentication information and the browser will only do so if the link is encrypted.
First of all, do I understand correctly that the second login is using the exact same mechanism as the first (via HTTPS)?
Does the first hit on a unsecured page create a new session, in addition to the one created during login?
Check if, on first login, the cookie is not set with the Secure flag (that means that the cookie should only be sent over a secured (HTTPS) connection).
You can specify your own session handling settings in a configuration file (rather than editing the CakePHP library file.) In the configuration file you can set session.cookie_secure to 0, which will take precedence over the setting in /cake/lib/session.php. This will allow the session cookie to be used for both SSL and non-SSL connections.
Here is a blog entry on the topic:
http://bakery.cakephp.org/articles/view/how-to-bend-cakephp-s-session-handling-to-your-needs
and some documentation from the Cookbook:
http://book.cakephp.org/view/173/Sessions
You can read more in documentation CakePHP at
http://book.cakephp.org/2.0/en/development/sessions.html
CakePHP’s defaults to setting session.cookie_secure to true, when your application is on an SSL protocol. If your application serves from both SSL and non-SSL protocols, then you might have problems with sessions being lost. If you need access to the session on both SSL and non-SSL domains you will want to disable this:
You open file Config/core.php and add as bellow
Configure::write('Session', array(
'defaults' => 'php',
'ini' => array(
'session.cookie_secure' => false
)
));
Now you can switch http and https that not lose session :)
Has your homepage got any flash on it that makes a subsequent request to your server? Or any Ajax loading of content?
Have you checked headers being sent from the server? In IE you can use Fiddler or in Firefox use the Live Headers addon. Check for any new cookies being set or the CAKEPHP cookie having a different value.
Just bumped into this problem, I commented the following and it worked fine:
<br />ini_set('session.name', Configure::read('Session.cookie'));
<br />
from session.php (/cake/lib/session.php, line 480~)