<p><a href="https://craftcms.com/classreference/services/UserSessionService#saveCookie-detail" rel="nofollow"><code>craft()-&gt;userSesssion-&gt;saveCookie()</code></a> is basically a fancy wrapper for <a href="https://craftcms.com/classreference/services/HttpRequestService#getCookies-detail" rel="nofollow"><code>craft()-&gt;request-&gt;getCookies()-&gt;add()</code></a> that (as you've discovered) does some key and value based hashing to ensure that cookie data hasn't been tampered with between requests.  Which is especially useful if, for example, cookies are used to maintain user session.</p>

<p>If that's not the behavior you're looking for, you can use PHP's <code>setCookie</code> method (like <a href="https://github.com/lewisjenkins/craft-lj-cookies" rel="nofollow">LJ Cookies</a> and the <a href="https://github.com/nystudio107/cookies" rel="nofollow">Cookie plugin</a> do) or you can interact with <code>craft()-&gt;request-&gt;getCookies()-&gt;add()</code> directly outside the context of the UserSesssion service.</p>

CC BY-SA 3.0
2016-02-24T19:41:48.857Z
Thanks Brad – the call to `getCookies()->add()` is a nice workaround.
Mats Mikkel Rummelhoff
CC BY-SA 3.0
2016-02-24T19:29:25.187Z
2016-02-24T19:29:25.187Z
Brad Bell
<p>I'm trying to set a cookie using <a href="https://craftcms.com/classreference/services/UserSessionService#saveCookie-detail" rel="nofollow noreferrer"><code>saveCookie()</code></a>, and I'm puzzled by the UserSessionService's behaviour.</p>

<p>Instead of creating a plain old cookie, Craft actually creates a so-called <em>state</em> cookie, where the cookie name is prefixed with a hash key and the cookie value is also hashed.</p>

<p>Here's the code I'm running to set the cookie:</p>

<pre><code>craft()-&gt;userSession-&gt;saveCookie('myAwesomeCookieName', $someAwesomeCookieData, 3600)
</code></pre>

<p>...and here's what the cookie looks like:</p>

<pre><code>d9c79699028b2f1b123abbcd3e872e5dmyAwesomeCookieName : aa9de09d72cdbda2caac4551870e073d0f7307b3s
</code></pre>

<p>Reading over the source code, docs and <a href="https://craftcms.stackexchange.com/a/656/1098">other SE's on the subject</a>, it's not apparent to me why Craft creates a state cookie instead of a regular (non-hashed) cookie.</p>

<p>Also, as far as I know, the only built-in method available to <em>templates</em> for retrieving a cookie is <code>craft.request.getCookie</code> – which is actually unable to read <em>state</em> cookies, so it all seems a bit odd.</p>

<p>I've currently implemented template variables for retrieving and reading the state cookie in my template (by wrapping the UserSessionService's <code>getStateCookie</code> and <code>getStateCookieValue</code> methods, respectively) but I'd love to know why the hashing happens in the first place, and if I can prevent it without an additional plugin (I'm aware of the <a href="https://github.com/lewisjenkins/craft-lj-cookies" rel="nofollow noreferrer">LJ Cookies</a> and the <a href="https://github.com/nystudio107/cookies" rel="nofollow noreferrer">Cookie plugin</a>). </p>

<plugin-development><templating><cookies>
Why does the UserSessionService create a *state* cookie?
# Why does the UserSessionService create a *state* cookie?

(Asked by: username_0 on 2016-02-24)

I'm trying to set a cookie using saveCookie(), and I'm puzzled by the UserSessionService's behaviour.
Instead of creating a plain old cookie, Craft actually creates a so-called state cookie, where the cookie name is prefixed with a hash key and the cookie value is also hashed.
Here's the code I'm running to set the cookie:
craft()->userSession->saveCookie('myAwesomeCookieName', $someAwesomeCookieData, 3600)

...and here's what the cookie looks like:
d9c79699028b2f1b123abbcd3e872e5dmyAwesomeCookieName : aa9de09d72cdbda2caac4551870e073d0f7307b3s

Reading over the source code, docs and other SE's on the subject, it's not apparent to me why Craft creates a state cookie instead of a regular (non-hashed) cookie.
Also, as far as I know, the only built-in method available to templates for retrieving a cookie is craft.request.getCookie – which is actually unable to read state cookies, so it all seems a bit odd.
I've currently implemented template variables for retrieving and reading the state cookie in my template (by wrapping the UserSessionService's getStateCookie and getStateCookieValue methods, respectively) but I'd love to know why the hashing happens in the first place, and if I can prevent it without an additional plugin (I'm aware of the LJ Cookies and the Cookie plugin).

**Tags:** plugin-development, templating, cookies


---

## 1 answers

### Answer by username_1 on 2016-02-24. Score: 1 | Accepted answer

[`craft()->userSesssion->saveCookie()`](https://craftcms.com/classreference/services/UserSessionService#saveCookie-detail) is basically a fancy wrapper for [`craft()->request->getCookies()->add()`](https://craftcms.com/classreference/services/HttpRequestService#getCookies-detail) that (as you've discovered) does some key and value based hashing to ensure that cookie data hasn't been tampered with between requests. Which is especially useful if, for example, cookies are used to maintain user session.

If that's not the behavior you're looking for, you can use PHP's `setCookie` method (like [LJ Cookies](https://github.com/lewisjenkins/craft-lj-cookies) and the [Cookie plugin](https://github.com/nystudio107/cookies) do) or you can interact with `craft()->request->getCookies()->add()` directly outside the context of the UserSesssion service.

> **Comments:**
> **username_0**: Thanks Brad – the call to `getCookies()->add()` is a nice workaround.  

---

