I am facing a strange scenario. basically on my every web page i am doing
session_start();
if(!isset($_SESSION['login']))
header("Location: login.php");
to ensure every user has logged in first. I am working in chrome and what happens is if I login to my web application and open any page it works fine. At the same time if, in another tab, I login to my hosting server, I am logged out of my web application. If I login to my application again, I am logged out of my hosting server!!
What am I doing wrong? is there a problem the way I am checking or setting the session variable?
I am setting the session as follows:
//if authentication successful
session_start();
$_SESSION['login'] = "1";
I have a very similar problem, and I think this happens just because two sessions with the same name, in the same place of the same domain can't coexist.
Maybe a solution should be to use session cookies. You can set a cookie just for a folder and not for the whole domain. This way I think you can manage 2 sessions at the same time, but I'm not sure.
Try this:
session_start();
setcookie(session_name(), session_id(), 0, '/public/');
Where /public/ might be the specific folder where your site is located, or the application path (thanks Paul for pointing out this).
Then you will check if session is set:
$session_cookie =
isset($_COOKIE[ini_get('session.name')]) ?
$_COOKIE[ini_get('session.name')] :
null;
Probably this won't work, since the other session might be "stored" in the root folder of your web application. But if you are able to do the thing above also for your hosting server, you should resolve your problem.
You can also try to set a different name for the session in your web application.
Hope this helps.
I think you'll find the cause is that both hosts have the same network name e.g. test.www.example.com and www.example.com
Just use a different network name for the test machine and it should work or make sure you explicitly use non-overlapping values for session.cookie_domain
Related
I use a test domain in laravel and one subdomain is in use. Everything works fine,
test.com and user.test.com
but, Login function does not work on test domain
I have verified that the session file is generated at stoage / sessions
when I done login, it does not cognize my session. The login function works well on localhost url. how i can fix that?
i'm done config like this below
config / session.php
domain => ".test.com"
And if I set up like above, can I share login information between two domains?
Clear the cookies for the site and then try to log in again. Or If the issue still persists then try to change Session Cookie Name in config/session.php
I'm following the following URL to set up sessions for user logins to multiple subdomains.
PHP Multi-Domain Sessions; ini_set Not Working?
I manage to get it working using the following format:
ini_set('session.cookie_domain','.domain.com');
session_start();
The problem now is that this only works at times on my subdomain.
When it doesn't work, sessions are not detected on xxx.example.com but are active on www.example.com.
I use a common login page from my main domain http://www.example.com/login so if sessions are detected on the main site, the login page wouldn't work as i do a header redirect to the main page whenever sessions are detected.
It will only work when i clear my browser cache, resetting all the sessions and try logging in again.
Anyone knows where the problem might be?
This affects my site overall User Interactivity. Any help will be appreciated.
You can try this code:
session_name("mss17");
session_set_cookie_params(0, '/', ".domain.com");
session_start();
We are having some issues with PHP Session Cookies not allowing us to log into our *SugarCRM** application which is open source PHP application.
The problem is we have the same application installed on 2 sub-domains like below...
Main site
www.domain.com
Dev site
dev.www.domain.com
Now after logging into one, it will not allow you to login to the other!
Please view the image below to see the Cookie problem...
In the image above you can see that there is 2 PHPSESSID Cookies competing for the Session!
If I now delete one of them, it allows me to login as normal without an issue!
Because this is SugarCRM, I am hoping I can resolve this issue without making really any core file modifications to the application. But if I have to, then we will.
So does anyone have any ideas on a good solution?
Right now my idea for a "Nasty Dirty Hack" which I really do NOT want to have to do. It is to make a button on the login form, this button will use JavaScript to clear/delete the PHPSESSID Cookies but again I would really like to find a proper solution.
If anyone has any ideas, please share? Thank you
UPDATE
Thanks for the answers so far. Please do take into acocunt that this is not a simple PHP application that I built where I can easily do code changes. THis is SugarCRM which is a massive large application with thousands of files
Try to setup in .htaccess parameter on subdomain
php_value session.cookie_domain .domain.com
or use in php code, but before "session_start()"
ini_set('session.cookie_domain', '.domain.com' );
Use
session_set_cookie_params
to set the session from the subdomain, on the principal domain.
Try to use function (http://php.net/manual/en/function.session-set-cookie-params.php):
session_set_cookie_params ( $lifetime, $path, $domain, $secure, $httponly)
And set one $domain = '.domain.com'
Or if you setting session cookie manually by setcookie, then setting the same domain too
Its actually not the domain you need to change, but the "session name" (name of the cookie parameter). Both apps seem to be using the default "phpsessid" and need to be made to differ, otherwise the apps will see eachother sessions, see the wrong session, or try to unserialize classes only defined in the other project.
You need to change the cookie parameter its storing the session ID in. It can be controlled from an environment variable (php.ini, .htaccess, etc.): http://us1.php.net/manual/en/session.configuration.php#ini.session.name
This way you can have multiple PHP sessions on the same domain. For example if you had example.com/sugarcrm and example.com/foo You could have sugarCRM store it's session ID in a cookie param called "sugarsession" (instead of the default phpsessid)
It has been a while since I had this issue but I think all you have to do is write each instances session file to a different directory by editing the config.php in each SugarCRM's file system and change the line
'session_dir' => '',
to point at a different directory.
I am using a system to log in to a site that uses a number of subdomains of a subdomain. I have a development and live version of this system, however I am experiencing strange behaviour.
So, the setup is I have the following:
Development environment:
dev.mydomain.com
sub1.dev.mydomain.com
sub2.dev.mydomain.com
Live environment:
live.mydomain.com
sub1.live.mydomain.com
sub2.live.mydomain.com
As part of the login process, I use the following line to set the cookie:
setcookie("LoggedIn", 1, 0,'/','.mydomain.com');
This all works fine and I can log in once and access everything, however I want to restrict it so that if I log in on the test system, then I am not logged in to the live system and vice versa.
I expected the solution to this to be:
setcookie("LoggedIn", 1, 0,'/','.test.mydomain.com');
and
setcookie("LoggedIn", 1, 0,'/','.live.mydomain.com');
dependent on the system.
However, using this method I am able to log in to test.mydomain.com and live.mydomain.com independently but I am unable to log in to the sub-subdomains (sub1.test.mydomain.com, sub2. etc).
What am I doing wrong?
It might because of same-origin-policy. Please go through it.
i totally agree with your expectation the subdomain cookie should have priority over top domain but in most web frameworks you can't have duplicate cookie id, so even if you set the cookie domain as top and subdomain still both are valid, so i think the safest solution is you should try to change the cookie id for that specific domain usually i put it in the application configuration as variable
I am developing a site on my localhost, where everything works fine, but now that the site is uploaded to the HTTPS side of our inserted ONLINE /inserted server, the $_SESSION variables don't get carried over from the login.php to the index.php page. Both are located on HTTPS, the process never goes out of HTTPS. As I said, everything worked fine on my localhost.
My localhost's PHP is version 5.3.2 and the HTTPS server is 5.2.6. The only difference in settings I can identify regarding sessions is session.use_only_cookies is On on my localhost and Off on the HTTPS server.
Can anyone please shed some light as to why the session variables are not transferred? PS. I do have session_start(); in both login.php and index.php.
Thanks in advance.
Have you checked that the session cookie is carried over between the HTTP and HTTPS requests? And that the same session token is present on both sides?
If the cookie established via the HTTPS page is marked as "secure only", it will not be transmitted to non-SSL pages, so you'd get a brand new empty session on the non-secure pages, which would give you the symptoms of "missing" session variables. They're not really missing, just in some other session which isn't active now.
There are a few things that can go wrong.
Make sure both login.php and index.php are accessed through https. session.cookie_secure defaults to off, but you never know.
Also make sure they are they both on the same domain. Cookies are set per-domain.
Maybe there is some oddball cookie setting? You can view the current session cookie settings with: session_get_cookie_params()
You can also verify how the cookie is being set in your browser (if at all), for Opera you can right-click in the page, select "edit site preferences", and use the "Cookie" tab. Don't know about other browsers from the top of my head ...
Another possibility is a borked session.save_path, run session_save_path() without any arguments to get the current session_save_path, make sure the user running PHP (typically but not necessarily the same user running the webserver) can write to this directory.