I have two domains that I want to communicate. I want the first domain to set a cookie in the second domain telling the second domain that the current user is known to the first domain. I understand that I cannot read cookies for another domain, but given that I have access to both, is there a way to accomplish this?
Both domains are implemented in PHP. One is a Drupal site and the other a WordPress site.
Server can't read cookie for another domain but, you can add cookie for another domain. When adding cookies, you should add double cookie. First your normal cookie and second for another domain. Both values are the same.
I am using a single php file, and that is included in many other websites using iframe, when two websites accessing same file via iframe, the session is not differentiated and php uses same session variable for different referring domains.
I want to restrict session referal domain wise.
Have you tried using $_SERVER['REMOTE_ADDR']?
Quoting: http://php.net/manual/en/reserved.variables.server.php
'REMOTE_ADDR'
The IP address from which the user is viewing the current page.
If you are accessing that 2 websites on one machine & one browser, there is no differences, Just like one person open a web page in 2 browser tabs => same session.
In 2 browsers, ofcourse they will be diffrent.
If you want different sessions in that case. Create session by your self, depends on referrer domain (parent page domain) / User Agent and User IP to create user session. Do everything else base on that session (Ignore default one).
You can use $_SERVER['SERVER_NAME'], which contains the current domain name the user uses.
I was brought aware of this issue by some users on my website. A user many enter into their browser http://xxxx.com and then login. Then they may click on a link that brings them to http://www.xxxx.com it asks them to login again! Is this a known issue that anyone has encountered before? I tried googling it but im not sure if im using the wrong keywords or what because i cannot find anything related to this.
Thanks,
Ian McCullough
As far as your browser is concerned, www.xxxx.com and xxxx.com are different domains. The same-origin policy prevents accessing cookies across domains.
However, the browser is aware of subdomains, and a subdomain can access the cookies of a parent domain. So, if you want to make your cookie accessible to both xxxx.com and www.xxxx.com, just set your cookie on .xxxx.com and you'll be set.
When you set a cookie, you can optionally specify which domain the cookie is set for. If you don't, the cookie is particular to that hostname only, and thus if the cookie is set on www.example.com, it will only be returned by the browser on that hostname or below.
If, when setting the cookie, you set the domain to "example.com" it should work also on "www.example.com".
The problem is that the more specific cookie will override the less specific one, so if you've previously set a cookie on "www.example.com" it will continue to override the new one set for "example.com", rather than being replaced by it - you would first have to delete the one set for "www.example.com". It gets tricky since when the client returns a cookie to the server it doesn't say which hostname the cookie was set for.
People seem to be assuming you're using a cookie to perform authentication but are skipping what appears to be your root question. Trevor briefly touched on it, but still kept to the cookie concept. As far as http is concerned, www.xxxx.com and xxxx.com are different subdomains on the same top level domain. Hence, while they may be the same ip, same website, same everything, the browser request and the server's response are considered to be 2 separate domains/sites. Sessions are not shared across subdomains unless you have a separated session state (such as a SQL Session store, etc).
However, if you are using cookies for authentication, you can add a check for the cookie and rebuild a fresh session if the data in the cookie is valid (and sufficient to reconstruct session). Otherwise you'll have to separate session state from the process into a data store.
Check the domain of the cookie, when creating a cookie you can specify if it is for all sub domains, the root server, specific sub domain, etc. To handle all, the cookie would be for .example.com
we are solving the problem with eshop (php, mysql). The client want to have the same eshop on two domains with shared shopping cart. In the shop customer can do the shopping without users account (can't be logged in). And there is the problem, how to make the shared shopping cart cross domain.
The data from cart is stored in sessions, which we stored in database too. But we can't solve the problem in carrying data over domains. Identifying unlogged user is not holeproof (research).
The example, how it should work
Customer goes to domainOne and add some things to the cart. Than he goes to domainTwo (by link, typing domain address, however) and add some other things to the cart. In the cart he has things from both domains (after refreshing page).
Do you have any idea, how to solve this problem?
What didn't work:
redirecting is not possible due to customer requirments
cookies are related to domain
set_cookie with the other domain didn't work
the simpliest way is to carry over only the sessionid (stored in cookies) but we don't know, how to wholeproof identify unlogged users.
is there any other place, where data can be stored on client side except cookies? (probably not)
we can't use sending sessionid by params in url (if user click to link to the other domain) or resolving the header referer, bcs we don't know, how user can achieve the other domain.
If you can't understand me, take me a question. If you think, that having eshop on two domains with shared (common) cart is bad idea, don't tell me, we know it.
Thanks for each answer.
You can use a third domain to identify your customers over all domains.
Use for example a PHP File on http://thirdDomain.com/session.php that is included on all pages on both shops.
Sample:
<script type="text/javascript" src="http://thirdDomain.com/session.php"></script>
After your customer switches domains, you can identify him as the same customer using the third domain.
You can assign the session id on both shops to the session id on the third domain to access the cart on both shops. You only need to inform the third domain about your shop sessions (i.e. add them as parameter).
Depending on how flexible you are with your code and templates, you can even use an output from the third domain to define the session id in your shops. This way you can use the same session id on all domains.
But normally a session id assignment should be the more secure way.
Using the javascript version you can also output scripts that may add a session id to all outgoing links and forms to the other domain in the current html page. This might be interesting if you can identify your customer as having cookies blocked.
You can also use the javascript to inform the parent document about an existing session.
This keeps getting asked.
Have a search for SSO.
You need to pass the session id in the URL (or vai a POST) across the domains, then:
1) check the session does not already exist on the target domain
2) rebind the session using the session id sent
e.g.
if ((!$_COOKIE[session_name()]) && $_GET['passed_id']) {
if (check_session_exists($_GET['passed_id'])) {
session_id($_GET['passed_id']);
}
}
session_start();
...
function check_session_exists($id)
{
$path=session_save_path() . $id;
if (file_exists($path) && (time()-filemtime($path)<session_cache_expire())) {
return true;
}
return false;
}
This also means you need to add '?passed_id=' . urlencode(session_id()) to any URL pointing to the other domain.
C.
The schema is quite simple and widely used. By google for it's numerous services for example. You have a whole picture by tracking down HTTP interchange between your browser and various google services to get the idea.
Suppose we have our client authorized for the 1st domain. By getting to the second, we have to:
start a session and store some token in it.
ask browser to request 1st domain somehow and send this token along.
1st domain will recognize our client and make a connection in the shared database between this token and user id.
By requesting second domain again, we will have it authorized for it's already started session.
The only question remains is how to request 1st domain. It can be a picture, or JS request or entire page redirect. Certain choice is up to you.
You can use Flash LSO's for this matter i think. Normally LSO's are stored in their domain specific sandboxes, but if two domain objects allow, they can communicate as stated in the "cross-movie communication" section in http://download.macromedia.com/pub/flash/whitepapers/security.pdf.
For general info about LSO's:
http://www.adobe.com/products/flashplayer/articles/lso/
SSO.
CartA has iframe that 1) checks if the user is "active" (has session) 2) creates anon session
CartB has iframe that do 1) or 2)
iframe loads from SSO domain (any domain you can have)
SSO solution: build yours or use others - like simplesamlphp or something...
And there should be no need to pass sessions/params with URIs...
You can store data in other places than cookies (e.g. Flash cookies, localStorage) but all use same origin policy, which is the standard security model of the web: data stored by a domain can only be accessed by that domain and its subdomains. The standard workaround is to embed an iframe from the foreign domain into the page. That iframe will have access to the cookies of the foreign domain, and its url will be controlled by the local domain, which allows for communication.
A simple solution based on that is to have a table of (domainA sessionid, domainB sessionid) pairs. When a new user arrives to domainA, (new sessionid, NULL) is added to the table; the page shown to him includes an invisible iframe with source = http://domainB/mergeSessions.php?sessionA=1234. mergeSessions.php will then receive sessionA as an URL parameter and sessionB as a cookie, and update the session link table accordingly.
You could attempt to identify your visitors by IP, browser type, browser version, OS, screen resolution, and whatever else you come up with. That you store in the shared database when someone accesses either site.
If, within a small time window, say < 5 min, requests from that IP with those parameters comes, you can reasonably assume that it's the same user. Again, make sure you use everything you can find find to identify that user and by no means base anything secure on this or you will be subject to hijacking.
What about something like this, not sure how good it would be though.
User goes to store1. If user does not have a session cookie, redirect to a special page on store2 asking for the session id and sending the url on store1 to return to. The special page looks at the session cookie and redirects back to the original url on store1 with the session id (like the answer by #symcbean). Then on store1, the session cookie gets set(or created new) and no more redirecting happens. And then the same but oposite if the user is on store2 with no session cookie.
But if the user does not have cookies enabled, I can see an infinite loop happening. Not sure if it would be possible to detect and stop somehow.
But this way would be hacky at best.
1) Obviously, use the same session-store for both domains (files, database, memcached, the usual suspects.
2) If after session_start() the $_SESSION is empty, create an 'all domains' array in the session (do this on every domain, regardless which one it is, ).
$_SESSION['all_domains'] = array(
'domain1.com' => true, //<= current domain the customer is on,
'domain2.com' => false, //other domain, no cookie for it yet.
'domain2.com' => false); //repeat for all domains needed
3) Create a session-setter script on all domains (let's call it 'sesset.php':
<?php
if(isset($_GET['sessid']){
session_id($_GET['sessid']);
session_start();
//also, check here for the domains:
if(!isset($_SESSION['all_domains'])){
//set the array as before, flag this domain as true.
} else {
$_SESSION['all_domains'][$_SERVER['HTTP_HOST']] = true;
//you might want to set a custom domainname instead of HTTP_HOST, so you won't get doubles from domain with & without www. and so on.
}
}
?>
4) On every conceivable php HTML page, put this somewhere near the end of the body:
<?php
foreach($_SESSION['all_domains'] as $domain => $domainset){
if(!$domainset){
echo '<img src="http://'.$domain.'/sesset.php?sessid='.session_id().' width="1" height="1"/>';
}
}
?>
Not fullproof, but will get almost all users. Ofcourse, one could do it with a redirect cascade instead of 'hidden images', but searchbots (google et al.) very much get confused about it, especially if they don't remember the cookie and are stuck being redirected again & again.
easyXDM is a framework that allows the user to easily work around the Same Origin Policy.
Its built-in RPC feature is very easy to use, and you should be up in running in no-time.
For your case, select one of the domains to be the 'checkout'-domain (A) - this is the domain that will keep the session stored. On the same domain you create a small file with an easyXDM endpoint that is responsible for storing/retrieving the data sent from the other domain (B).
Now, in domain B, you include easyXDM and when storing/retrieving data from the cart, you access the RPC methods instead.
Option 1 Use Iframes:
Site 1 has an Iframe of site 2
Site 2 has an Iframe of site 1
When a user selects an item from site one, set the iframe value to a dynamic string ie domain2.com/iframe.php?itemid=someitem.
Have domain2 grab the $_GET information with PHP from the iframe and update the user's cookie.
Do the same in the other direction.
Option 2: Javascript includes
You can do something similar with cross-site included JS files generated by PHP to "pull" the contents of the user's cookie to the other site.
Option 3: Curl
Just post the data from one domain to the other, so both have a copy. This is the least secure method since there is no guarantee that the IP address or other identifying data can't be duplicated. Though, you can have some "question" or pass phrase to ensure it is the same person. Possibly by setting an email address?
Option 4: Third-party cookies
I think this one was already mentioned, but you can set the cookies from a third domain, so both sites functionally exactly the same rather than "toggling" back and forth between the two.
i am using php 5.2.8
i have index.html, which loads LOAD.PHP from IFRAME.
iframe src="load.php".....
i printed out load.php's session id.
then i ran another test.php, and printed out it's session id.
php session id's were different.
therefore, i cannot pass any session variables....
what is happening here ? this problem did not happen before, suddenly today it started happening.... however this problem still exists....its driving me nuts !
session.saved_path is same for both.... /var/php5, cookie path is same...
If PHP is creating a second session ID on the second load of the page, then it means that the first one was not passed back properly. Likely, the cookie is not being set for some reason. Things to check:
Test in multiple browsers?
Did you disable cookies in your browser somehow?
Is the iframe on a different domain or subdomain that might prevent cookie passing?
Install LiveHTTPHeaders or some other firefox add-in to check the cookies you are receiving
http://www.example.com will have a different sessionID than http://example.com
(not really an answer as your questions doesn't seem to me to have enough data to provice a certain answer, but rather a few things to check about)
The files are in the same domain and directory and the cookie are not limited to a different directory (i.e. path=/)? (note: they're not limited unless you tell that explicitly with session_set_cookie_params)
Is the browser sending the cookie (or are you maybe in "incognito mode")? If cookies don't work PHP will probably try to pass Session IDs in the QueryString and fail, if you go to test.php writing its name manually and not following a link (usually I use session.use_only_cookies=1 to avoid that).
They will have different SID if they have different cookie domain or cookies are not working at all and PHP is configured to use only cookies for session ID (session.use_only_cookies=1).
Cookies domain is explained here
Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: ".com", ".edu", and "va.us". Any domain that fails within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: "COM", "EDU", "NET", "ORG", "GOV", "MIL", and "INT".
The default value of domain is the host name of the server which generated the cookie response.
So set a common domain for your hosts and they will share cookies, thus PHP SID :)