I need to use the same session in different subdomains.
First I put
php_value session.cookie_domain ".aaaa.com"
on .htaccess file and upload it to root path.
when I need to use sessions. I just call
session_start();
Sometimes it works but sometimes it doesn't.
I tested this and found that.
If I go to login page the first time, then login and go to subdomain page. It works!
If I go to subdomain page and click to login page and go back to subdomain page by javascript window.location = 'http://sub.aaaa.com'; it does not work!!
If I login on 2 web browser with the same account it does not work!!
Are there another way? Or how do I fix this problem. I want my website to use a single login.
Make sure you have session_start() on every page you are using sessions, including some that might not be visible to the user.
If you are using two web browsers the sessions are independent from each other, and this is by design.
To debug your #2 problem, use an HTTP monitor such as HTTPFox to view the headers coming to/from the server as you log in and surf around, make sure the cookie is being properly set with the correct domain and path restrictions.
Probm #3 - I'm not sure what you're getting at. Are you using two seperate browsers (say Firefox and Chrome?), or do you mean you're using two windows/tabs of the same browser? For the first, two different browsers will not share cookies, so you can't share a single session between them, without doing some hacks to manually transfer cookies between them.
As for two different tabs/windows of the same browser, such an implementation depends on your login logic. If the login script starts a new session unconditionally, then you second login attempt will get a completely seperate session from the first login, and most likely overwrite the first login's cookie as well.
Related
I m creating a very simple PHP-based program for warehousing but quite complicated back-end process.
So here is the situation:
I have the login page that directs to authorization page where it set the session_name for the first time, session_start() and set the session variables.
After the authorization page, it goes to the main.php page that is a table with left hand side for menu (links) that I also did session_name() <-- same name as the one created from (1), and start the session.
On the right hand side of the main page is the iframe that display the page when user click the links on the left. I also did session_name() <-- same name as the one created from (1), and start the session.
Problem:
main.php is ok, it reads the session variable perfectly, but the iframe couldn't get the session variables (i tried to print_r($_SESSION), and came up empty). I tried var_dump(session_name("abc")), where "abc" is the session name that i used in (1), and it does show "abc", tried (isset($_SESSION)) and returns true... so I don't know what am I doing wrong...
EDIT:
I m sorry guys, i think i may have found the culprit... it is a logic error on my side... i have this condition to check every php page i created to destroy session when the user level is not authorized to use this current page. My bad.. thanks so much for your help guys!!
Make sure that session_start() is on all the pages:
session_start() creates a session or resumes the current one based on a session identifier passed via a GET or POST request, or passed via a cookie.
see PHP manual reference
To control the contents of the $_SESSION try to put in all ifreame pages the code:
<?php
session_start();
echo '<pre>';
var_dump($_SESSION);
echo '</pre>';
Did you use session_start() at the top of the page in both the iframe as well as main.php?
You need to put session_start() on the top of the iframe too.
This might solve your problem: php session & iframe
Additionally: Nothing is simple if you're using iframes to display large portions of your webiste. You might want to consider not using them.
I had the same problem with multiple iframes on one of my PHP webpages.
In my case, some AJAX calls to PHP endpoints were being made to www.example.com when the page was loaded using http://example.com. If you are NOT consistent with the domain path, you may have session issues since a request from www.example.com is technically from a subdomain as oppose to being made directly from http://example.com. You can avoid this problem altogether by always using relative paths to your PHP based API when making AJAX calls in JavaScript.
I found this was the case by inspecting my cookies in Chrome. I noticed two different cookies with a different PHP session ID in them. One was set for www.example.com while the other was set for example.com
As mentioned in some of the other answers, you can always set the session cookie domain to work on all of your subdomains along with your main site by using the following:
ini_set("session.cookie_domain", ".domain.com");
PHP by default will set a new session per domain / subdomain. Hope this helps!
I'v got this setup currently running, where a website is running at site.domain.tld with the backend beeing at admin.site.domain.tld
A somewhat SSOish system is to be installed at sso.admin.site.domain.tld. In fact, when visiting this site, the user is authenticated, a corresponding cookie is beeing set and the user is moved back to admin.site.domain.tld.
When I am setting a cookie like this
setcookie('bid', $bid, 0, '/', 'admin.site.domain.tld');
I'll get a cookie cookie that is issued for .admin.site.domain.tld (note the dot).
The login like this works fine, but if the user is going for whatever reason first to admin.site.domain.tld and then decides to log in using sso[...], we have a problem: The adminpage sets itself a cookie - but this time it is issued for admin.site.domain.tld - without the dot at the beginning.
So basically after using the sso-login this time, the user ends up with having two different cookies, one for admin.site.domain.tld, one for .admin.site.domain.tld
Because the admin-page prefers the cookies set directly for the page itself, the dot-cookie gets ignored and the login fails.
So basically the best way would be to read, modify or just delete the already existing cookiebut this seems to be impossible from the sso-subdomain.
"Because of reasons", we are not able to place our stuff from the sso-subdomain directly on the admin-subdomain.
Anyone here with an idea, what I could do the somehow get rid of those "bad" admin.-cookies?
Would it just be possible to use a different cookie name? You have one subdomain that reads and writes "cookie1" and then another subdomain that reads and writes "cookie2". Does that solve your problem?
I am using PHP sessions. I set the session using session_start() and set some session variables. Then, I use those session variables.
Now, say I open a page in my browser (http://example.com) and a PHP session starts. If I open another page in a new tab (http://www.example.com , notice www in the URL) the first session disappears.
What can be the solution to avoid this situation ?
Your session ID is stored in a cookie; cookies are only valid for specific domains. To brute force this problem, you need to use session_set_cookie_params (before session_start) to make sure the cookie is valid on all subdomains you are interested in (the $domain argument controls this).
However, a better approach would be to set up a permanent redirect from one of the domains to the other at the web server level; if you have a public site and you care about your search engine ratings at all it is imperative to do this in any case.
Actually what you should do, unless you have very good reasons to don't do it, is to use just one url. As far as I know it wasn't very SEO friendly to have different url to access the same content as the browser engines consider it duplicated content.
You should configure it to use the www always or don't use it at all. Fairly easy to do with the .htaccess file.
I have secured pages that all check for a set session variable to determine logged in users, pretty standard stuff. Where I run into problems is when I submit form information to a backend page that will process that data and then redirect to a success/failure confirmation page. In that time the session gets lost, at least the session with the variable. The session is still around because I can manually navigate to a secured page after and it works. Just auto redirects from a backend page to a secured page or a link on one of the unsecured pages after a redirect from the backend will fail. It may or may not be related, but after visiting multiple secured pages or doing one of the operations that use the problematic backend pages, there are two session cookies on my computer from the domain-- one registered to domain.com and the other to www.domain.com. At the end of my wits about this, thanks.
I see two problems here, but they're related.
The first is that you seem to be bouncing between secured (https://) and un-secured (http://) pages. Cookies aren't supposed to be shared between those, so that's why your session appears to break (PHP sets a cookie with the session ID).
The other is closely related and that is sharing between domain.com and www.domain.com. Cookies can share in one direction, but not the other. Don't worry about which: just pick one hostname and stick with it. Then check that you're setting the session's cookie domain to the correct one.
You must call session_start() from your PHP page before you output anything, preferably at the start of the page.
If the session has been already created, it will resume it for that page.
http://php.net/manual/en/function.session-start.php
I have a site which I have been testing in a sub-folder of my client's site-root.
I had no log in problems during testing, but then I moved the new site files from a sub-directory to the main site root, and now I'm losing my logged in state after almost every page refresh in secure areas.
I am running a $_session based login system that refreshes the session id on every page load, with a comparison value stored in the MySQL database.
Does anyone have suggestions for what could be causing this problem?
krico was right in suggesting that the cookie path may be the cause (but the solution proposed seems a bit daft) however you've said that is not the case.
Check to see exactly what cookies (name, path, expiry, flags) are being set and returned by using iehttpheaders (MSIE) LiveHeaders (Firefox) or using a network sniffer like wireshark. Then ask the question again providing details of what you found out.
C.
Cookies are usually path relevant. Your previous sub-directory based site was probably setting the cookie (that binds the browser to the user) only for that sub-directory.
A way to fix it is to put a redirection page on the old subdir that adds a cookie to '/' and then redirects to new site on root.
If you change session id you will loose all data stored in previous session. You must set session name after every session start command
<?php
session_name('AnySessName');
?>
or use other mechanism to store your variables cross sessions.