I have the following problem - a third party software is setting a cookie with the login credentials and then forward the user to my app. I now need to retrieve the cookie values:
The problem is - I can do this easily in the Frontend/AS3 with
var ticket : String = CookieUtil.getCookie( 'ticket' ).toString();
but in PHP, the cookie is not within the $_COOKIES array.
The cookie values are:
Name: ticket
Domain: .myserver.com
Path : /
Send for: encrypted connections only
Expires: at end of session
The one I see, and set before in PHP, is:
Name: myCookie
Host: myserver.com
Path : /
Send for: any type of connection
Expires: at end of session
Actually, since host/domain are both the same, it should be visible in the PHP script, since it is running on this domain.
Any thoughts? Thankx
Martin
I don't know if this can be useful for you but, the PHP manual (cookie section) states:
Any cookies sent to you from the client will automatically be included into a
$_COOKIE auto-global array if variables_order contains "C".
You should check the php config variables_order directive in order to be shure the Cookie flag is set.
ahahah got it! $_COOKIE not $_COOKIES :)
get a habit to program in PHP with error_reporting(E_ALL) reporting level, to avoid such a silly mistakes
Could this be domain sub domain issue? I mean www.myserver.com is not 'under' .www.myserver.com ... ?
The cookie should have the domain set to ".myserver.com"
Currently the only way to get this cookie is to have a script living under ".www.myserver.com" like "app.www.myserver.com"
EDIT: The OP had a typo. But are cookies with domain "myserver.com" members of ".myserver.com" ?
Any thoughts?
Actually, cookie is not a text file. But merely HTTP header.
So, to see a real cookie, one must watch HTTP interchange log, not the files on the client PC.
I am sure watching HTTP log would bring some light on the situation. It can be dome in many ways, LiveHTTPheaders mozilla addon for example.
Both Cookie and Set-Cookie headers are to count.
Related
I need to set the PHPSESSID coockie for just two domains:
www.domain.tld
sub.domain.tld.
Other subdomains should not share the same PHPSESSID.
I can use session_set_cookies_param(), but as far as I can see, this can only set it for one domain or all subdomains.
But in my case, subdomain anothersub.domain.tld should not have this PHPSESSID.
I want this because we have images on a subdomain, and setting the PHPSESSID for all subdomains causes the browser to send the PHPSESSID cookie with the request. This has slight performance issues for static resources and it is recommended to use cookieless domains
This can't be done this way, this is unrelated to PHP. This is how cookies works in general. Only one domain (or a domain with a dot in front) can be set.
You have to use different domain for image hosting.
While as was already explained, this is not technically possible, due to the cookie “syntax”, I think you should be able to work around that, if you simply set a second cookie yourself.
Use session_set_cookies_param to have it set the cookie for www.domain.tld only.
Add your own code after session_start, that sets the “same” cookie again, just for sub.domain.tld this time.
session_name and session_id help your figure out the necessary name and value; if you want, you can also use session_get_cookie_params to match other parameters (like lifetime and maybe path, if the latter makes any sense in the given setup) as well if you like.
Edit: Keep in mind though, that if the session id might change at any other point within your app after session_start, for example if session_regenerate_id is used anywhere, you will of course have to update your second cookie there as well.
For a period of time cookies were set on a single site with different values for the domain. This resulted in some people having cookies with the same name set for both .www.domain.com and .domain.com. The site is intended to be accessed as www.domain.com. This is accomplished with .htaccess rules.
The code will use .domain.com. now for the session.cookie_domain going forward.
The issue I am having is that when both cookies exist the browser sends both (both are valid). I see this is so in the headers and also when dumping out apache_request_headers(), however, when I dump out $_COOKIE I see just one of them.
["Cookie"]=>
string(74) "foobar=hkej4qdnq5kismiq3kl07qv6k2; foobar=ocvn7anlu2f2k2l37nl9ou3c21"
And then...
array(1) { ["foobar"]=> string(26) "hkej4qdnq5kismiq3kl07qv6k2" }
My session interface read($id) method is checking the old cookie and not the one we set on login.
What is the best way to address this? I am thinking I could just change the session name/identifier and start fresh. Or maybe evaluate the Apache headers in my read implementation. I have not found much that is relevant in searching the web, just a bunch of fluff from w3schools polluting the results, so I thought this might be a good one to post here.
I had the same problem and solved it by changing the session name.
PHP allows you to access the variable $_SERVER["HTTP_COOKIE"] and parse it yourself. This allows you to access both values, of the cookie, but you can still not tell apart the correct and the wrong cookie.
Unless those cookies contain really valuable data, I would not care about the old values and just start new.
Just change the session name from PHPSESSID to SITESESSID or something else of your choice. This will make sure that your application ignores the old cookie all together. If the lifetime of your session is 0, then its a SESSION Cookie(Gets deleted when the browser is closed), in such case you can change the session name back to PHPSESSID after a few days or a month of implementation since you will be sure that no one has the old cookie.
BTW: The browser isn't sending two cookies. It's just your old session cookie still alive.
If I belong to the no-www camp, cookies I have set in http://example.com would be read by http://sub-domain.example.com,
And regardless of the language I use (perl / asp.net / php / JSP) there is no way I could ever work around this issue because it is a fundamental architecture of HTTP itself, true or false ?
What I'm concerned here is, is there any DNS config that would prevent http://sub-domain.example.com from reading the cookies set in http://example.com ?
I have a domain name http://qweop.com
I have a subdomain at http://sd.qweop.com
Now, the problem is that even though I've not set any cookies on http://sd.qweop.com, when I read the cookies, there are cookies there. They are reading cookies from http://qweop.com.
How do I fix the problem so that the cookies from the main domain would not be read by (a request to) the sub-domain?
I've tried altering the 5th parameter of the php setcookie function but it doesn't seem to do anything. Basically that parameter is like useless. I'm suspecting it's a limitation of the HTTP infrastructure.
DETAILS:
http://qweop.com/set.php (try to use incognito to allow easy cookie removal)
<?php setcookie("testcookie","testvalue",time()+60*60*24*30,"/","qweop.com");?>
cookies set
http://sd.qweop.com/read.php
<?php print_r($_COOKIE); ?>
// No one had set any cookies in http://sd.qweop.com but we can see cookies here! Error!
Answer: Yes
I had better catalog the answer here after 500 hours of google research.
Basically we should always use www if we're planning to use any other sub-domains and we want them cookie-free. This is because there are different browser behaviors with regards to top-level domain cookies.
We can try our best to tell the browser "Hey's set it to just the domain and not to it's sub-domains" but as long as the url is non-www, they won't be nice and behave the way we want them to.
In fact, even if the url is not non-www, they can still do whatever they want to, there is currently no record of any browser that does that (and most likely so too into the future).
I believe you cannot do anything about it. You might try to set the cookie as:
setcookie('some_name', 'some_val', 0, '/', 'yourdomain');
but it will be set to all subdomains of yourdomain even though RFC 2109 says if the cookie is to match the subdomains it should be set with a dot as .yourdomain. All major browsers are sending it to the subdomains. I checked it with IE, FF and Chrome.
Unfortunately, DNS config has absolutely nothing to do with cookies (as long as they belong to the same 2-nd level domain, of course).
You still can have a practical answer if you ask a practical question though.
I've set a cookie just fine, and the cookie is in the request header, but when I access that cookie in the PHP superglobal $_COOKIE it isn't set. Dumping $_COOKIE shows the other cookies but one, and all were in the request header.
If I dump $_SERVER I can see that cookie in $_SERVER['HTTP_COOKIE']. PHP sets all of the cookies into $_COOKIE but one.
What could cause this and whats a fix?
Server is running PHP 5.3.3.
Update:
At the top of my index.php I var_dump($_SERVER); and then var_dump($_COOKIE); on the next line, and an expected cookie isn't printed from the second dump.
Update2:
Here's the Cookie part of my request
Cookie:SESSe00cd0d8b79da0906c77d52ed6e26907=2f9fhsomr2skcfmivagb1i8gj7; __utma=172891446.852439441.1310775539.1310775539.1310775539.1; __utmc=172891446; __utmv=172891446.%3A; __utmb=172891446.4.10.1310780296; OATMEAL=%9Ey%EE%C9J%956%C0%06%B3%EBZ%83%D1%80%C0%AC%D2%D0T%86%9A%2A%2A%A2E%B7f%86%D7i%C1%28%19L%1Fl%920%3CE%10%B6%C9c%1D%E3%A7H%D9%E1%29%1C%7E5%C8q%CC3%21C%0C%DC%CC%A5%F3i%10%F7%DCJjF%EE%B9%80%3C%C6Jy%A2%0E%3F%E3%BD%7B%BF%CD%84%85%91%BB3%B9%EA%CB%92%89%AC%FBc%BA%A32s%B5L%3E%DF%9B%CDk%08%DEZ%13%5Da1Q%B0%1CJ%90%AE%AF%3F%15%98%1B%E1%C1g%A9%BBzR%F5Q%82%8F%81%1A%D1%0E%87%DC%F3%3B%FF%B7%8E%09%0F%BF%DFK%A3t%D1%F3%DA_%ECKt%01%00x%D2%CCE%24%BB0%C2w%B4%82%F0Q%00O%F1v%19%11%0A%3A%BB%9Fy%B1%BC9hgy%C4%DC%DEN%C4%A4%3B%7D%E8%84h%07%E3+%0B%85y%8B%B5y%1B%FC%CE%86B%F55%ED%E0%01%EB%18%13%B0%09%CA%F9%3D%26%05%FC%A7%F8%E4%CD%3C%9E%D7%24%B1%BF%27t%B4%3C%89%D76%F0%CF%C0%D4%E7Z%A6%02%19j%D7%60%28%82%DF%DF%9C%05%25%CB%CA%04%B9%21N%D2r%A76%DD%D1%CB%97%B0%A9%13%29%3C%D6kdm%D1%14%EA%D4%1Fz%F9%CF%21i%BD%19RN%C3%8Dh%27R%15%99%13%FAv%13%8F%BBd%7B%F5%AD%D5%22%13q%13Z%F219%B9%B0_%AB%16%7B%D2%18%E3%F0%F6%9D%A4X
The cookie that's dropped is named "OATMEAL".
Update3: This PHP bug sound similar https://bugs.php.net/bug.php?id=52018
Your string is 1099 characters long.
Max length for a Cookie is 4Kb.
Assuming UTF-8 characters with 4 bytes per char you should be able to store between 1024.
Try to make OATMEAL smaller. Much smaller and let us know if that was the culprit.
You shouldn't use the value in $_SERVER["HTTP_COOKIE"]. It's not documented, so it's probably not reliable.
This message in comments for the setcookie function might answer your question.
Note that the $_COOKIE variable not will hold multiple cookies with the same name. ...
Could it be that you have not set the right path for the cookie? I have had problems with this before where it would not let me access the cookie because it was being set to a strange path automatically. I had to specify the correct path when I set the cookie.
You probably already know this but sometimes things can hide right under our noses.
http://us3.php.net/manual/en/function.setcookie.php
cheers,
Michael
As others have already said, it's almost certainly to do with the length of your cookie string. You should make it shorter.
It's also worth pointing out that even if it works, there's a very good reason for not having such a long cookie string -- the entire cookie string gets sent in both directions for every single HTTP request you make.
Let's say you have a typical page, that loads twenty images, two CSS files and two Javascript files, plus the main HTML page itself. For a 1K cookies string like yours, that would be an extra 50K on your server's bandwidth (and your user's bandwidth) for every single page load. That's going to add up quickly if you've got a reasonable amount of traffic, and if you've got any kind of limits or metering on your bandwidth, it's going to cost you extra money.
Secondly, I don't know what that OATMEAL cookie contains; I don't have the time to decode it, but it looks a lot like you're obfuscating data (including adding some deliberate spoiler characters). Be aware that if this data is sensitive enough to want to obfuscate, then the cookie is a really bad place to be storing it.
If you really do need to pass that amount of data to the server, you should be sending it in a POST request. If the PHP program needs to access it with subsequent page loads, then set it in your $_SESSION array. If your Javascript code needs to be able to use it or set it, then use an Ajax request.
Thanks everyone, but offline from this thread another dev suggested base64 encoding the cookie data when sent. That worked and kept the data alive and I was able to base64 decode server-side and continue on.
I have been losing my session variables rather consistently when I click on the link from our websites notification email. After breaking my head for a long time on this, I today realized that www.domain-name.com does not contain the session variables while domain-name.com does!!
Why does this happen? And what do I do to set things right(php-apache)?
Sessions are based on cookies, which are per-domain.
www.domain.com is a different domain than domain.com, so their cookies are kept separate.
Standard practice is to choose one variant and 301 redirect the other variant to the preferred one.
The session ID is stored in a cookie, and in the cookie can be specified how it should react over domain names.
Take a look at PHP's setcookie documentation.
You can change PHP's session cookie configuration with:
ini_set("session.cookie_domain", ".mydomain.com");
There's nothing technically special about ‘www’. The domain ‘domain.com’ is distinct from ‘www.domain.com’; if you want to associate them, that needs to be explicit somewhere, usually in the HTTP server configuration.
How to redirect with .htaccess file:
http://papermashup.com/useful-htaccess-techniques/
http://perishablepress.com/press/2006/01/10/stupid-htaccess-tricks/#red2