we are running an online portal which is available via different domains (e.g. example.de, example.at, example.ch) as well as variations of it (e.g. exam-ple.de) and payment for all countries is done via secure.example.com, so it is not possible to access cookies on secure.example.com which were set on example.de.
First question (not directly refering to cookies):
Is it possible to forward a user from exam-ple.de to example.de without loosing the referer information? Maybe with .htaccess?
Second question:
Is it "dirty" to store all cookie names in a configuration file and then pass all cookies via GET everytime the user gets forwarded to another domain name and reset the cookies? I can only think of this one solution to make cookies available on different domains... Or does anyone has a better solution for the problem?
Best regards,
Freddy
To answer your first question, assuming that you are using apache2 as the web server (you told about .htaccess) , I would suggest using mod_rewrite for redirecting the urls to a different domain. When using mod_rewrite you are enabled to set cookies
Also you can create a php script that forwards to your domains and sets the cookies. It might be called like www.yourdomain.com/forward.php?target=at&....
Related
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.
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'm running Ubuntu / nginx and php-fpm. When I open my website http://www.mydomain.com I have to log in and a session is being created by PHP. When I log on to http://mydomain.com I have to log in again and another session is being created.
How can I prevent PHP from creating new sessions and stick with one? Or is this rather a web server issue?
This is because your sessions are based on cookies, and cookies are domain specific. www.domain.com is technically a subdomain of domain.com, although it is rarely treated as such, and the browser will act as if it were a completely different server. You can work around the problem by passing the session id as a GET (or POST) parameter as appropriate.
See this page or the PHP manual for an explanation of how to do it. All you really need to do is include the constant SID in all your links etc - this is defined when you call session_start() and is a string in the format of a URL parameter.
Use session_set_cookie_params and set the domain to .mydomain.com. Also session_set_cookie_params needs to be called before each session_start
You need to specify the cookie domain to make sure the cookie is seen valid for both www and non-www http://php.net/manual/en/function.session-set-cookie-params.php
I'm trying to maintain a web site spread across two domains with the same host (one is actually in a subfolder of the other):
www.a.com -> /.../public_html/
www.b.com -> /.../public_html/b/
I have one script on a.com, let's call it public_html/readcookiedata.php, which reads in some session variables from a cookie. Another script on b.com, let's say public_html/b/index.php, needs to also read this cookie.
Right now index.php tries to require_once(../readcookiedata.php).
This works great if I visit www.a.com/b/index.php: the cookie is read OK.
However, if I browse to there directly, www.b.com/index.php, the cookie isn't read.
What's the best way to fix this problem? Is there a way for a.com to allow b.com to read its cookies? Or some way to configure the host to treat all requests to b.com as if they were for a.com/b/ instead?
No. Cookie security is built into the web at a browser level; browsers literally won't allow you to read data for cookies from other domains on pages served by a different domain.
In the application I'm writing using a combination of development environments and languages, I have need of accessing a cookie from two different subdomains, each on a separate host.
The cookie is being set on www.mydomain.com using the PHP code that follows, and I'm attempting to access it from distant.mydomain.com on a separate host.
setcookie('token', base64_encode(serialize($token)), time()+10800, '/', '.mydomain.com');
I'm trying to access the cookie from distant.mydomain.com using the following code:
if (isset($_COOKIE['token'])) { /* do stuff */ }
The problem: distant.mydomain.com is not finding the cookie. The if statement just mentioned returns false, even though the cookie exists.
I have verified that the cookie that is set is for mydomain.com (by checking my Firefox cookies). I can't think of any reason this wouldn't be working.
Using the same setcookie code, I have an old application running exclusively on the www.mydomain.com host, and that application is able to access the cookie across domains. This makes me suspect that the problem has to do with separate hosts.
Just in case any of the following information is pertinent:
- www.mydomain.com is IIS 6.0
- distant.mydomain.com is Apache 2.2.9
- Both servers use PHP 5.2.x
- Both servers are operating on Windows Server 2003
If there is any further information I can provide in order to better describe the problem, please let me know!
For the benefit of anyone reading this question the code and information contained in the original post are exactly correct and work fine.
The problem is when you introduce other technology. For instance, I have since learned that sending PHP code through a Python module, one that allows Django to serve PHP files/content, changes a great deal about what is accessible to the script and what is not.
This was eventually discovered following the advice of Marc Novakowski, who suggested sending $_COOKIE to the log in order to find out what was there.
I also checked out $_SERVER and $_GET. It was the emptiness of $_GET that tipped me off that the setup I am attempting to use is not as straightforward as I had thought. It was that mistaken understanding that led to not including the information about Django in the original post.
Apologies and thanks to all who responded to this question!
Cookies set in domain
'.aaa.sub.domain.com'
will collide with identically named cookies set in domain
'.sub.domain.com'
and '.some.stupidly.obscure.multi.sub.domain.com'
That means (and this took some time to wade thru) if you're going to use the same-named cookie across multiple domains, you must set it once (and once only) in the main/base domain, in this case '.domain.com'; otherwise, the resulting cookie will be indeterminantly and randomly returned arrived at, sometimes the cookie 'jasper' set in .a.sub.domain.com, sometimes the cookie 'jasper' set in .sub.domain.com, sometimes the cookie 'jasper' set in .b.c.d.domain.com, sometimes the cookie 'jasper' set in '.sub.domain.com' and sometimes the cookie 'jasper' set in '.domain.com'
Does one of the subdomains use an underscore ? IE has problems accepting cookies from subdomain's that dont follow the URI RFC.
This is asumming 'distant' is a placeholder and not the actual subdomain name and of course that you use IE. Although more browsers could very well be effected by as, Fireworks doesn't though.
I'd try installing Charles Proxy and see what headers are a) being sent to Firefox to begin with (to set the cookie) and b) which headers are being sent from Firefox to the second server. At least that way you can narrow down where the problem is (browser or server).
From php.net about the setCookie-function:
The path on the server in which the cookie will be available on. If set to '/', the cookie will be available within the entire domain . If set to '/foo/', the cookie will only be available within the /foo/ directory and all sub-directories such as /foo/bar/ of domain . The default value is the current directory that the cookie is being set in.
The domain that the cookie is available. To make the cookie available on all subdomains of example.com then you'd set it to '.example.com'. The . is not required but makes it compatible with more browsers. Setting it to www.example.com will make the cookie only available in the www subdomain. Refer to tail matching in the ยป spec for details.
Basically: Your 4. and 5. parameter needs to be checked: Well, your path seems to be fine, but the domain needs to be changed:
Today you block the cookie to all others than domain A, but you want it to be awailable to both domain A and B. This is a bit tricky, but can be solved. Get inspiration on 15seconds ;-)