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.
Related
I have this script that works well on other servers but the session part fails on a particular host. I have pointed to another server but would really like to figure out what could be the problem. I have observed that :
It takes 5-15 mins for changes on code to reflect(e.g changing
text on index page).The server seems to cache pages especially index
(BTW i cleared my browsers cache e.t.c)
When i logout and login as another user the server still retains
the session of the last user on the index page (the other pages seem
OK)
I can open index.php (without logging any user) and what i
believe is the last logged in users details display
I tried swapping my code for some authentication systems on github (just to be sure) even PHPAuth which uses cookies (not sessions) fails the same way. But the same code works flawlessly on localhost as well as other servers.
So i would like to figure out exactly what goes on on that host. It is a shared hosting package.
Got a reply from the host. Seems the problem was with the hosts session variable path. They fixed it.Thanks
I'm trying to fix a really elusive bug where I lose my session upon redirect.
In my local setup, there is no problem; it only manifests itself on the live site. I discovered that my local version was creating two identical cookies: one for .mydomain.com and one for www.mydomain.com. However, the live site creates only one cookie for .mydomain.com.
It seems as though my script is looking for the www.mydomain.com cookie, which is why there's no apparent problem on the local server.
How do I determine to which domain a given script will look for its cookies? (or if this sounds like a different problem, please let me know)
Use setcookie(key, value, expire_time, '/') this will add cookie for your site's document root, either www.domain.com or domain.com will work fine.
We have about 100 users accessing our website daily. A majority of them have no issues logging in. However, once a month we get a call or email ticket with complaints that users just see the login page refresh, with no error messages or anything.
All error messages are sent through the PHP Session cookie, and of course everything after logging in is based off of that session. The only reason I could think that the page just refreshes HAS to be because they are blocking that session cookie on their local machine...
Now most often the user is on internet explorer, but occationally it even happens with Chrome or Firefox. I've even had a user (on OSX) who tried Safari, Chrome, FF - and it would NEVER let them log in, the page would just basically refresh. I had the user add the website as trusted, and still no luck.
It's the worst because I cannot reproduce it from any network or from any browser/computer, ever.
Does anyone know what could be causing something like this? The site IS forcing SSL (the HTACCESS file redirects to HTTPS). The site IS forcing the session cookie as HTTP-Only and the Secure flag is also set to TRUE (and these 2 are somewhat recent changes).
I'm unsure what other settings on the server or the PHP instance would be causing something like this, or if it's soley a client-side issue (which it appears to be). And if it's client side, I'd like to learn the issue and possible solutions to it.
To preempt everyone, no - I cannot share the website URL for debugging because the client would not appreciate that, unfortunately. Thanks for any help, I'll be happy to answer any question that I can!
Do you have more than one web server behind a load balancer? And are the PHP sessions stored locally on each web server? If so it is the load balancer's job to make sure a user keeps going back to the same server on repeated accesses. If something goes wrong, they could get sent to a server where they do not have a session. It could be some intermittent glitch sending users to the wrong server.
Just guessing, because as others noted, we don't really have enough info.
Does your session cookie have a valid name? I've run into this problem in the past where some browsers don't accept a session cookie if it has an invalid name, but other browsers do accept them;
http://php.net/manual/en/function.session-name.php
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've got a newly set up dev server of a site I built. The dev server sits at a completely different Box and IP.
The dev site is a complete copy of the live site minus updates to paths and databases. The address is dev.mysite.com as opposed to just mysite.com.
The live site has a number of subdomains attached to it that change skins based on the subdomain, but nothing else is changed. When I try to log in to the dev site, it won't set the Session variable for the login. Any thoughts on this would be greatly appreciated.
Before testing the live site you should test and ensure that the dev site works. In your question it sounds a bit the other way round. Anyway, I see two options here:
conflicting cookies
missing server configuration on the dev site
From your question it's hard to say which of those two applies (even not even something else). You should concentrate to get your dev site to work, ignoring your life site. That means, you access the dev site with a complete different browser from a complete different box (if possible) and from a complete different internet connection (if even possible). That should help you to isolate the problem and more easily find out what is going on. Then get sessions to work on the dev site. After it works, you can start to test your live site.
I got a solution for you
— Create a cookie and set it for domain and all subdomain (*)
So you need to insert sessions to database, I suggest you to use Zend Sessions.
Documentation : http://framework.zend.com/manual/en/zend.session.savehandler.dbtable.html