Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-24T19:41:48.857Z
Answers.Text: Thanks Brad – the call to `getCookies()->add()` is a nice workaround.
Answers.UserDisplayName: Mats Mikkel Rummelhoff
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2016-02-24T19:29:25.187Z
Answers.LastActivityDate: 2016-02-24T19:29:25.187Z
Answers.UserDisplayName: Brad Bell
Body: <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>
  
Tags: <plugin-development><templating><cookies>
Title: Why does the UserSessionService create a *state* cookie?
ThreadText: # 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()`](https://craftcms.com/classreference/services/UserSessionService#saveCookie-detail), 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](https://craftcms.stackexchange.com/a/656/1098), 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](https://github.com/lewisjenkins/craft-lj-cookies) and the [Cookie plugin](https://github.com/nystudio107/cookies)).
  
  **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 username_1 – the call to `getCookies()->add()` is a nice workaround.  
  
  ---
  
  