I have successfully set a cookie cad and can see it in firefox cookie-search.
if(isset($_COOKIE['cad'])){
echo'YES';
}else{
echo'NO';
}
//parse NO
I am setting up my website on a hosted server, about to change from another so the server is site.com.test.host.com. Does that create problem for calling the cookie?
But talking against that is that print_r($_COOKIE); shows other Cookies on the same test-domain.
When you set a cookie, you can set various options. Cookies, as everyone knows, can only be accessed by scripts on the same domain, but you can also affect what path the cookie is set on. For instance, a cookie set on /foo/bar.php may not be accessible on /foobar.php.
PHP by default sets the cookie to the current path. So, with the above example, the cookie is set to the path /foo/, and is not accessible outside that path.
When you set your cookies, therefore, it's best to be explicit about where you want them to be available. In PHP this is very easy; just set an extra parameter specifying the path. As you indicate in the comments, you need the most liberal path possible /, which means "anywhere on this domain".
setcookie('cad', 'somevalue', 0, '/');
See the setcookie documentation in the PHP manual.
Related
I'm coding a simple cookie deleter and I don't know what to add in order to delete a cookie. It goes like this:
Click this and delete cookie
And the borrap1c0.php document says:
<?php
setcookie("prod1foto", "", time() - 3600);
unset($_COOKIE['prod1foto']);
setcookie("prod1foto", null, -1, '/');
header("Location: http://www.google.com");
?>
It's funny because it redirects me to google once I click on the link to borrap1c0.php but the cookie doesn't die.
Any ideas on how to kill the cookie?
Edit: Apparently this was caused because borrap1c0.php was stored in a different folder than the php file that generated and echoed the cookies. I don't know why but the problem was solved by putting both files inside the same folder, if someone can clear it up for someone else to understand it in case of having the same problem it would be helpful.
Apparently this was caused because borrap1c0.php was stored in a different folder than the php file that generated and echoed the cookies. I don't know why but the problem was solved by putting both files inside the same folder, if someone can clear it up for someone else to understand it in case of having the same problem it would be helpful.
See the path parameter in the setcookie docs:
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.
So, by default, setting a cookie in a subdirectory makes that cookie only exist within that subdirectory. You can set a path of / when creating your cookie to make the cookie apply domain-wide.
Try this:
setcookie("prod1foto","",time()-1);
Don't worry about manually unsetting the cookie, you need to expire it.
I have created one php web page which creates a cookie. That web page redirects the user on another (second) php web page. On this second web page I'm trying to delete the cookie which is created by the first page. But cookie is not getting deleted. And the second web page shows an error like "can not modify header information"
My php code format for deleting that cookie is like:
if(isset($_COOKIE['cookieName']))
{
setCookie('cookieName','values',time()-3600,'/','example#domain.com',0);
}
I hope you are making use of unset()
Do like this
if(isset($_COOKIE['cookieName']))
{
unset($_COOKIE['cookieName']));
}
Can you try this,
unset($_COOKIE['cookieName']);
setcookie('cookieName', null, -1, '/');
Path:
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.
Domain:
The domain that the cookie is available to. Setting the domain to 'www.example.com' will make the cookie available in the www subdomain and higher subdomains. Cookies available to a lower domain, such as 'example.com' will be available to higher subdomains, such as 'www.example.com'.
Setting cookies is done in the HTTP header. This header is sent before the actual content of the page. As a result, you can only (un)set the cookie of you have not yet sent any output.
This is also stated in the setcookie documentation:
Like other headers, cookies must be sent before any output from your
script (this is a protocol restriction). This requires that you place
calls to this function prior to any output, including and
tags as well as any whitespace.
For example:
<?php
if (isset($_COOKIE['cookieName'])) {
unset($_COOKIE['cookieName']);
setcookie("cookieName", "", time()-3600);
}
?>
<html>
....
</html>
(Also see the question Remove a cookie.)
I only want the session cookie on www.website.tld and www.apps.website.tld, using ini_set if possible. Also i need to set all cookies i write to both subdomains only. I do not want www.imgs.website.tld to have the cookies. the php session one i'm kinda unsure of. The cookies i set my self my idea was to call SetBothCookie($name,$value,$time) a custom function.
function SetBothCookie($name,$value,$time)
{
setcookie($name, $value, $time, "", "www.website.tld", 1);
setcookie($name, $value, $time, "", "www.apps.website.tld", 1);
}
So i think i have the SetBothCookie part down, but wanted to see what others think of that code. The part i'm stuck on is having php set the session cookie on both sub domains. I'm using session_set_save_handler to override the default php session storage to store sessions in the database, so both servers can use the same session data. From my understanding is if i put Javascript that does http requests on the www.apps.website.tld to www.website.tld it won't allow them to happen, and i want that added security, so thats my reason of running only a part of the site on a subdomain.
This function should work but...
Using secure parameter in set_cookie() according to PHP manual
Indicates that the cookie should only
be transmitted over a secure HTTPS
connection from the client. When set
to TRUE, the cookie will only be set
if a secure connection exists. On the
server-side, it's on the programmer to
send this kind of cookie only on
secure connection (e.g. with respect
to $_SERVER["HTTPS"]).
So I suggest to remove 6th parameter of set_cookie() function.
Also, you can call this function before any output or it will throw a warning like
Warning: Cannot modify header
information - headers already sent by
(output started at ...) in ... on line XX
Using session_set_save_handler() is good solution to take control over session variables.
If you want cookies for entire domain just use "/" or ".website.tld" (with initial dot according to RFC 2109 standard) for domain parameter (5th in a row). Parameter path should be "" (empty string; 4th).
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"); ?