Php set cookie and session

[PHP 4, PHP 5, PHP 7, PHP 8]

setcookie — Send a cookie

Description

setcookie[
    string $name,
    string $value = "",
    int $expires_or_options = 0,
    string $path = "",
    string $domain = "",
    bool $secure = false,
    bool $httponly = false
]: bool

setcookie[string $name, string $value = "", array $options = []]: bool

Once the cookies have been set, they can be accessed on the next page load with the $_COOKIE array. Cookie values may also exist in $_REQUEST.

Parameters

» RFC 6265 provides the normative reference on how each setcookie[] parameter is interpreted.

The name of the cookie.

The value of the cookie. This value is stored on the clients computer; do not store sensitive information. Assuming the name is 'cookiename', this value is retrieved through $_COOKIE['cookiename']

The time the cookie expires. This is a Unix timestamp so is in number of seconds since the epoch. One way to set this is by adding the number of seconds before the cookie should expire to the result of calling time[]. For instance, time[]+60*60*24*30 will set the cookie to expire in 30 days. Another option is to use the mktime[] function. If set to 0, or omitted, the cookie will expire at the end of the session [when the browser closes].

Note:

You may notice the expires_or_options parameter takes on a Unix timestamp, as opposed to the date format Wdy, DD-Mon-YYYY HH:MM:SS GMT, this is because PHP does this conversion internally.

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 [sub]domain that the cookie is available to. Setting this to a subdomain [such as 'www.example.com'] will make the cookie available to that subdomain and all other sub-domains of it [i.e. w2.www.example.com]. To make the cookie available to the whole domain [including all subdomains of it], simply set the value to the domain name ['example.com', in this case].

Older browsers still implementing the deprecated » RFC 2109 may require a leading . to match all subdomains.

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"]].

When true the cookie will be made accessible only through the HTTP protocol. This means that the cookie won't be accessible by scripting languages, such as JavaScript. It has been suggested that this setting can effectively help to reduce identity theft through XSS attacks [although it is not supported by all browsers], but that claim is often disputed. true or false

An associative array which may have any of the keys expires, path, domain, secure, httponly and samesite. If any other key is present an error of level E_WARNING is generated. The values have the same meaning as described for the parameters with the same name. The value of the samesite element should be either None, Lax or Strict. If any of the allowed options are not given, their default values are the same as the default values of the explicit parameters. If the samesite element is omitted, no SameSite cookie attribute is set.

Return Values

If output exists prior to calling this function, setcookie[] will fail and return false. If setcookie[] successfully runs, it will return true. This does not indicate whether the user accepted the cookie.

Changelog

Examples

Some examples follow how to send cookies:

Example #1 setcookie[] send example

Note that the value portion of the cookie will automatically be urlencoded when you send the cookie, and when it is received, it is automatically decoded and assigned to a variable by the same name as the cookie name. If you don't want this, you can use setrawcookie[] instead. To see the contents of our test cookie in a script, simply use one of the following examples:

Example #2 setcookie[] delete example

When deleting a cookie you should assure that the expiration date is in the past, to trigger the removal mechanism in your browser. Examples follow how to delete cookies sent in previous example:

Example #3 setcookie[] and arrays

You may also set array cookies by using array notation in the cookie name. This has the effect of setting as many cookies as you have array elements, but when the cookie is received by your script, the values are all placed in an array with the cookie's name:

The above example will output:

three : cookiethree
two : cookietwo
one : cookieone

Note: Using separator characters such as [ and ] as part of the cookie name is not compliant to RFC 6265, section 4, but supposed to be supported by user agents according to RFC 6265, section 5.

Notes

Note:

You can use output buffering to send output prior to the call of this function, with the overhead of all of your output to the browser being buffered in the server until you send it. You can do this by calling ob_start[] and ob_end_flush[] in your script, or setting the output_buffering configuration directive on in your php.ini or server configuration files.

Common Pitfalls:

• Cookies will not become visible until the next loading of a page that the cookie should be visible for. To test if a cookie was successfully set, check for the cookie on a next loading page before the cookie expires. Expire time is set via the expires_or_options parameter. A nice way to debug the existence of cookies is by simply calling print_r[$_COOKIE];.
• Cookies must be deleted with the same parameters as they were set with. If the value argument is an empty string, and all other arguments match a previous call to setcookie, then the cookie with the specified name will be deleted from the remote client. This is internally achieved by setting value to 'deleted' and expiration time in the past.
• Because setting a cookie with a value of false will try to delete the cookie, you should not use boolean values. Instead, use 0 for false and 1 for true.
• Cookies names can be set as array names and will be available to your PHP scripts as arrays but separate cookies are stored on the user's system. Consider explode[] to set one cookie with multiple names and values. It is not recommended to use serialize[] for this purpose, because it can result in security holes.

Multiple calls to setcookie[] are performed in the order called.

See Also

• header[] - Send a raw HTTP header
• setrawcookie[] - Send a cookie without urlencoding the cookie value
• cookies section
• » RFC 6265
• » RFC 2109

walterquez ¶

9 years ago

Instead of this:


You can this:


Bachsau ¶

10 years ago

Want to remove a cookie?

Many people do it the complicated way:
setcookie['name', 'content', time[]-3600];

But why do you make it so complicated and risk it not working, when the client's time is wrong? Why fiddle around with time[];

Here's the easiest way to unset a cookie:
setcookie['name', 'content', 1];

Thats it.

Anonymous ¶

2 years ago

Just an example to clarify the use of the array options, especially since Mozilla is going to deprecate / penalise the use of SameSite = none,  which is used by default if not using array options.

paul nospam AT nospam sitepoint dot com ¶

15 years ago

Note when setting "array cookies" that a separate cookie is set for each element of the array.

On high traffic sites, this can substantially increase the size of subsequent HTTP requests from clients [including requests for static content on the same domain].

More importantly though, the cookie specification says that browsers need only accept 20 cookies per domain.  This limit is increased to 50 by Firefox, and to 30 by Opera, but IE6 and IE7 enforce the limit of 20 cookie per domain.  Any cookies beyond this limit will either knock out an older cookie or be ignored/rejected by the browser.

nacho at casinelli dot com ¶

5 years ago

It's worth a mention: you should avoid dots on cookie names.

Anonymous ¶

15 years ago

something that wasn't made clear to me here and totally confused me for a while was that domain names must contain at least two dots [.], hence 'localhost' is invalid and the browser will refuse to set the cookie! instead for localhost you should use false.

to make your code work on both localhost and a proper domain, you can do this:

gabe at fijiwebdesign dot com ¶

15 years ago

If you want to delete all cookies on your domain, you may want to use the value of:



rather than:



to dertermine the cookie names.
If cookie names are in Array notation, eg: user[username]
Then PHP will automatically create a corresponding array in $_COOKIE. Instead use $_SERVER['HTTP_COOKIE'] as it mirrors the actual HTTP Request header.

MrXCol ¶

11 years ago

If you're having problem with IE not accepting session cookies this could help:

It seems the IE [6, 7, 8 and 9] do not accept the part 'Expire=0' when setting a session cookie. To fix it just don't put any expire at all. The default behavior when the 'Expire' is not set is to set the cookie as a session one.

[Firefox doesn't complains, btw.]

bluewaterbob ¶

15 years ago

if you are having problems seeing cookies sometimes or deleting cookies sometimes, despite following the advice below, make sure you are setting the cookie with the domain argument. Set it with the dot before the domain as the examples show: ".example.com".  I wasn't specifying the domain, and finally realized I was setting the cookie when the browser url had the //www.example.com and later trying to delete it when the url didn't have the www. ie. //example.com. This also caused the page to be unable to find the cookie when the www. wasn't in the domain.  [When you add the domain argument to the setcookie code that creates the cookie, make sure you also add it to the code that deletes the cookie.]

user at example.com ¶

2 years ago

As of PHP 7.3.0 the setcookie[] method supports the SameSite attribute in its options and will accept None as a valid value.

For earlier versions of PHP,  you can set the header[] directly:

header['Set-Cookie: cross-site-cookie=bar; SameSite=None; Secure'];

lferro9000 at gmail dot com ¶

5 years ago

Of notice, the cookie when set with a zero expire or ommited WILL not expire when the browser closes.

What happens is that the browser, when closes the window, if it is a well behaved browser, will delete the cookie from the cookie store.

However, the cookie will survive in the server until the garbage collector removes the session, which will happen only when it kicks in and checks the specified session is out of bounds of the setting stated in:

//php.net/manual/en/session.configuration.php#ini.session.gc-maxlifetime

Please check also:

//php.net/manual/en/session.security.ini.php

And in case of doubt, PHP runs on the webserver and has no way whatsoever to interact with a browser apart from receiving requests and answering with responses, so assuming that a cookie will be removed from a browser is just an "hint" for the browser. There is no warranty that such will happen as instructed.

That is one of the reasons why the cookie values sent to browsers by some platforms are encrypted and timestamped, to ensure that they are actual and not tampered.

ellert at vankoperen dot nl ¶

8 years ago

Caveat: if you use URL RewriteRules to get stuff like this: domain.com/bla/stuf/etc into parameters, you might run into a hickup when setting cookies.
At least in my setup a change in one of the parameters resulted in the cookie not being 'there' anymore.
The fix is simple: specify the domain. '/' will usualy do fine.

gareth at gw126 dot com ¶

16 years ago

You can use cookies to prevent a browser refresh repeating some action from a form post... [providing the client is cookie enabled!]



Hope that helps :]

Gareth

Anonymous ¶

1 year ago

Chrome versions prior to version 67 reject samesite=none cookies. And starting in Chrome version 84 samesite=none cookies without the secure attribute are also rejected. But that doesn't mean you can't set cookies on an unencrypted connection. The simple way around it is to use browser sniffing to detect samesite=none compatible browsers:

$cookie_string = 'set-cookie: name=value';

if [!preg_match['/Chrom[^ \/]+\/[[0-9]+][\.0-9]* /', $_SERVER['HTTP_USER_AGENT'], $matches] || $matches[1]>66 && $matches[1]

ahmetantmen at msn dot com ¶

15 years ago

You can be sure about the cookie files contents weren't changed.



Create a unique id for your site and create a hash with md5[$Data.$uniqueID]. Attacker can understant that it must be re-hash after change cookie content.
But doesn't. Because cannot guess your unique id. Seperate your hash and data with seperator and send that cookie. Control that hash of returned value and your unique id's is same returned hash. Otherwise you have to stop attack. Sorry for my poor english!

dmitry dot koterov at gmail dot com ¶

7 years ago

Note that at least in PHP 5.5 setcookie[] removes previously set cookies with the same name [even if you've set them via header[]], so previously fired Set-Cookie headers with e.g. PHPSESSID name are not flushed to the browser. Even headers_list[] doesn't see them after session_start[]:

header["Set-Cookie: PHPSESSID=abc; path=/; domain=.sub.domain.com"];
header["Set-Cookie: PHPSESSID=abc; path=/; domain=.domain.com"];
print_r[headers_list[]]; // here you see two Set-Cookie headers with domains for PHPSESSID
session_id['abc'];
session_start[];
print_r[headers_list[]]; // here you don't; you see only one Set-Cookie produced by session_start[]

Anonymous ¶

2 years ago

To add the "samesite" attribute, you can concatenate it to the path option until it gets implemented/documented properly
Eg:


byz ¶

6 years ago

exmaple with test.com；

setcookie['empty_domain','value',time[]+3600,''] 
equal       test.com

setcookie['test_com_domain','value',time[]+3600,'','test.com']  
equal       .test.com

setcookie['dot_test_com_domain','value',time[]+3600,'','.test.com'] 
equal       .test.com

ps:   .test.com   has its self    and child domain

jay at w3prodigy dot com ¶

12 years ago

You can also delete cookies by supplying setcookie an empty value.

setcookie["w3p_cookie", ""];

Carl V ¶

17 years ago

If you want to delete all the cookies set by your domain, you may run the following:



Very useful when doing logout scripts and the cookie name may have changed [long story].

Anonymous ¶

3 years ago

I haven't seen this mentioned here and had a lot of issues [and created a lot of stupid hacks] before I figured this out.

If you have a couple of environments for example, and are trying to set cookies on two domains:

example.com [main site]
dev.example.com [dev site]

In this case your [same named] cookies will interfere with each other if you're trying to set cookies with the domain parameter.

Simply use an empty string for the domain parameter and the cookies will refer to each host separately.

If you use the subdomain www. on the main site this won't be an issue, but without a subdomain you'll have issues with reading each others' cookies.

Anonymous ¶

12 years ago

A period in a cookie name [like user.name] seems to show up in the $_COOKIE array as an underscore [so user_name]. This means that for example $_COOKIE["user_name"] must be used to read a cookie that has been set with setcookie["user.name" ...], which is already rather confusing.

Furthermore the variable $_COOKIE["user_name"] will retain the value set by setcookie["user.name" ...] and no amount of calling setcookie["user_name" ...] will alter this value. This is rather trivially fixed by clearing the "user.name" cookie, but it can take a while to realize this since there's only "user_name" in $_COOKIE.

Hope this saves someone some time.

stovenator at gmail dot com ¶

15 years ago

If you are having issues with IE7 and setcookie[], be sure to verify that the cookie is set via http for http sites, and https for https site.

Also, if the time is incorrect on your server, IE7 will also disallow those cookies from being set.

jdknock [at] gMaIl [dot] com ¶

11 years ago

IE7 can have trouble with settings cookies that are embedded in an iframe. The problem lies with a W3C standard called Platform for Privacy Preferences or P3P for short.

To overcome, include the header:

header['P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"'];

before setting the cookie.

cwillard at fastmail dot fm ¶

15 years ago

If you're looking to set multiple values in your cookie [rather than setting multiple cookies] you might find these useful.


Hopefully someone finds these useful.

hansel at gretel dot com ¶

15 years ago

The following code snippet combines abdullah's and Charles Martin's examples into a powerful combination function [and fixes at least one bug in the process]:



Basically, if the domain parameter is supplied, it is converted to support a broader range of domains.  This behavior may or may not be desireable [e.g. could be a security problem depending on the server] but it makes cookie handling oh-so-much-nicer [IMO].

mkmohsinali at gmail dot com ¶

11 years ago

#cookies.php
/*This code will demonstrate use of cookies with PHP
It is very easy to understand and is better for beginner to
understand and get idea about power of cookies when used
with PHP.Here we give user a form to choose colors he/she
likes for website and when he/she visits site again within one
hour his/her settings are saved and read from cookie
and he/she doesn't have to set the page color and page
text color again.You can change time from 3600
seconds to whatever you deem appropriate in your case.
if you don't understand anything please email me*/

jonathan dot bergeron at rve dot ulaval dot ca ¶

15 years ago

About the delete part, I found that Firefox only remove the cookie when you submit the same values for all parameters, except the date, which sould be in the past. Submiting blank values didn't work for me.

Example :
- set -



- delete -


Jonathan

chris at styl dot ee ¶

11 years ago

I was searching for a simple example of creating a cookie, storing a random number and updating it on refresh. I couldn't find one so I had to figure it out on my own....

- - - -
One thing to *NOTE* is technically you can't update a cookie, you can only overwrite it with a new one with the same name.

- - - -

This creates a random number, stores it in a cookie, then references it on refresh, checks for duplicates and does necessary correction, then stores it again, rinse and repeat...