I'm trying to set a cookie which tracks what page the user is on, so that I can forward this in a websocket header, however when I do this:
setcookie("PAGE", $_SERVER['PATH_INFO'], 0, "/");
Which should be setting a cookie to something like %2FCommission%2F1 (/Commission/1), creates the cookie, which shows in firefox developer tools for a split second, then disappears (it doesn't show at all in chrome developer tools).
But if I manually set the cookie value as such:
setcookie("PAGE", "%2FCommission%2F1", 0, "/");
The cookie works perfectly fine.
I have tried trimming $_SERVER['PATH_INFO'], along with replacing potentially problematic parts, but nothing seems to work, if $_SERVER['PATH_INFO'] is used in any capacity in the creation of the string passed into the cookie value, I get this behaviour. Am I missing something?
Related
I've got to be missing something simple, but this is driving me batty.
I'm setting a whole bunch of array cookies, like so:
setcookie("adjusted[$title]", $title, time() + 3600, "/", ".domain.com");
This works just fine, the cookies are being set and I can see them in the browser's cookie list.
However, I can't seem to read only certain values back out! I have no idea why. For example, I set this cookie:
adjusted[calldelivernow.net]
and I can see that is its name in Firefox's cookies page, the content is "calldelivernow.net". But all attempts to do this return false:
if(isset($_COOKIE["adjusted"]["calldelivernow.net"]))
die("Cookie is set");
This is just one example of many, all under identical parameters just with different domain names. What on earth am I missing here? How can a cookie plainly exist in the browser, yet PHP not be able to read it?
Because you're not calling it by it's name correctly. Unlike form names, cookies do not get stacked to arrays.
Try $_COOKIE["adjusted[calldelivernow.net]"].
The problem appears to be that cookie names, cannot contain periods! Strangely, Firefox is in fact showing that the cookie name is correct and contains the period, but the $_COOKIE array replaces the period with an underscore, like so: ["calldelivernow_net"]=> string(4) "test"
here is my raw login page
http://wordswithfriends.net/mytourney/login.php
test user as follows:
l: testuser
p: test1234
Username displays here:
http://wordswithfriends.net/mytourney/test_cron.php
However if I wrap the above in an iframe as follows:
http://wordswithfriends.net/?page_id=386
Cookies don't seem to work. To show this login using both with and without iframe. Log out using iframe.
http://wordswithfriends.net/mytourney/test_cron.php
Still shows the username. Log out using
http://wordswithfriends.net/mytourney/index.php
Which is exactly the same page. Now the username disappears. How can I get consistency between the two?
There's a very subtle difference:
www.wordswithfriends.net (host: .wordswithfriends.net)
wordswithfriends.net (host: wordswithfriends.net)
Your cookies are clashing since the host domains are different. When you set the cookie, include the domain with a .domainname.net using setcookie():
setcookie("cookiekey", $value, time()+3600, "/", ".wordswithfriends.net", 1);
(or however you do it)
And this will make sure it works for all domains, not just wordswithfriends.net.
NOTE
You might also want to adjust:
session_set_cookie_params(time()+3600, '/', ".wordswithfriends.net", true)
In case your session cookie needs to be adjusted too. session_set_cookie_params()
Your iframe has www.wordswithfriends.net as the domain, your page does not. Try either using a wildcard cookie *.wordswithfriends.net or match the two domains.
I think this hack will help you because it seems to be a thirdparty cookie problem - but it's a kind of freaky a little bit...
so i need a cookie set for 21 days on a browser when a user hits the site and everytime the user returns in that 21 day period i need to retrieve that value
if($_REQUEST['ref'] == "something"){
setcookie('something_value', "something" ,time()+60*60*24*21,'/','mydomain.com');
}
in the view
<?php if(isset($_COOKIE['something'])) { ?>
but when i view the cookies in safari and firefox i dont see "something"
am I missing something
Looks like you've swapped the first two parameters of setcookie. The first parameter should be the name of the cookie.
// prefix the mydomain.com with a . (makes it work on more browsers)
setcookie('something_value', "something" ,time()+60*60*24*21,'/','.mydomain.com');
I've also had that problem and putting a . in front of the domain name made wonders for me.
Do not view cookies in safari and firefox. Cookie is an HTTP header and nothing else. Do not rely on inner browser's mechanism. But rely on HTTP log only. Do you see your cookie in HTTP log?
what is it's name? "something_value"? Don't you mess something? ;)
I came across the snippet below:
setcookie('foo', 'v1', time() + 60*60*24, '/');
setcookie('foo', 'v2');
What is the effect of setting 2
cookies with same name but different
values?
Is it common in practice?
Where is it used?
The above example will simply overwrite the first cookie with the second one. If you want to update a cookie to store a newer value, you can overwrite its value.
Two cookies may have the same name if they were set for different domains or paths. example :
<?php
setcookie("testcookie", "value1forhost", time(), "/", ".domain.com", 0, true);
setcookie("testcookie", "value2forsubdom", time(), "/", "subdom.domain.com", 0, true);
?>
The v1 vs v2 part makes it look like a trick to detect a cookie handling bug in the browser: if foo equals v1, the browser did not process the value change.
It'd be interesting to know about the code context.
Edit
Will it set 2 cookies or will it
overwrite
It depends on where you call the script from. A setcookie() call without a path sets a cookie for current path (where path is an URL path, not the internal file system path). So a call from http://example.com/ would create a single cookie and a call from http://example.com/somewhere/inside/ would crate two separate cookies, one for / and one for /somewhere/inside/.
I think this is not intended. The second cookie call will overwrite the original set cookie. After the first call there is no knowing if browser support is available, as no input from the browser is received when processing a script. A cookie is sent as a HTTP header, and sent back by the browser on consecutive requests.
Situation:
I'm trying run an https store (xcart) under one domain secure.example.com and I want to have access to a cookie it sets in http www.example.com
I'm running PHP on Apache (MAMP), testing in Firefox with Firecookie
The existing code sets cookies to .secure.example.com. I'm not sure if this is xcart related, but setcookie is actually called using secure.example.com. I'm not sure why the "." is appended.
Problems:
When I try to use setcookie in https to use the domain .example.com or just example.com, no cookie is created, whether I'm running the store under http or https. The testing code I'm using is:
setcookie('three', 'two', 0, "/", ".example.com");
If I set the cookie to secure.example.com or .secure.example.com it does show up.
Is there a reason the cookie isn't showing up?
The problem was that I was using localhost with a one word domain, 'mydomain', a fact which for some reason was edited out of the original message. At least firefox requires at least two words for an explicitly set cookie, something like mydomain.local. I changed the hosts file to have the domains: www.mydomain.local and secure.mydomain.local, and I was able to set the cookies to .mydomain.local.
Also I found that php automatically puts a "." in front of explicitly set cookies.
Yes - but the policy is determined by the browser (and on some browsers can be configured).
IIRC the semantics of the preceding . are explained in the cooke RFCs (2109 for the standard cookies states:
A is a FQDN string and has the form NB, where N is a non-empty name
string, B has the form .B', and B' is a FQDN string. (So, x.y.com
domain-matches .y.com but not y.com.)
Which I would interpret as meaning that a domian in a setcookie directive intended to be used as a wildcard match should be preceded by a '.' i.e. .example.com - however the spec goes on to say:
Domain=domain
Optional. The Domain attribute specifies the domain for which the
cookie is valid. An explicitly specified domain must always start
with a dot.
Which to me implies the opposite.
I suggest you read it yourself and experiment.
The obvious practical solution is, in the absence of a suitable cookie, to redirect back to the cookie-setting webserver for it to check its cookie then send back another redirect to the originating server with cookie details in the query string, then drop a copy of the cookie associated with the current server.
Alternatively you may get some mileage out of using FQDNs with more sections, e.g.
secure.www.example.com
and
www.example.com
(dropping the cookie for [.]www.example.com)
HTH
C.
Did you try setcookie('three', 'two', 0, "/", ".mydomain.com"); ?