<p>The reason Craft stores the user agent string in the authentication cookie when logging in is to help prevent session/cookie hijacking.  If will validate that it is the same subsequent requests on the presumption if your cookie is hijacked, there's a significant chance that the browser that stole the cookie will have a different user agent string that the one the session was started with.</p>

<p>Granted, this isn't fool proof (user agent strings are easily spoofed) and some browsers store their version number (like you discovered) in the user agent string as well.  This is all well-and-good until your browser decides to auto-update, forcing the string to change and then auto-logging you out of Craft, which looks like what you're seeing.</p>

CC BY-SA 3.0
2016-03-04T18:22:31.863Z
2016-03-04T18:22:31.863Z
Brad Bell
<p>I recently ran into an issue that I was able to fix with what feels like a workaround – updating the config setting <a href="https://craftcms.com/docs/config-settings#requireMatchingUserAgentForSession" rel="nofollow">requireMatchingUserAgentForSession</a> to <code>false</code>.</p>

<p>While I expect something changed on the website where I needed to do this, I'm not sure what would have changed and am curious if anybody with deeper knowledge of how user agents and sessions work could help explain what factors are at play here.</p>

<p>In my situation, members of the site were getting logged out shortly after they logged in and, while I could login to the control panel and navigate to several pages, each time I tried to access the Users tab, no users would display and I'd get logged out.  Each time this happened the corresponding item in the logs referenced a discrepancy between the user agent in the cookie and the current user agent.  The specific error message was:</p>

<blockquote>
  <p>Tried to restore session from the the identity cookie, but the saved
  user agent (Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_3)
  AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109
  Safari/537.36) does not match the current userAgent (Mozilla/5.0
  (Macintosh; Intel Mac OS X 10_11_3) AppleWebKit/537.36 (KHTML, like
  Gecko) Chrome/48.0.2564.116 Safari/537.36).</p>
</blockquote>

<p>The error outlines a discrepancy between <code>Chrome/48.0.2564.109</code> in the cookie vs the current <code>Chrome/48.0.2564.116</code>.</p>

<p>What scenario creates a discrepancy between the User Agent in the cookie and the current User Agent? What variables can change that cause a previously working membership site, to require suppressing differences in these variables to work?  Does suppressing this required match and allowing for differences in the current User Agent and the session open up possibilities for other issues to arise?</p>

<users><error-message>
Does setting requireMatchingUserAgentForSession to false have any additional implications to be aware of?
# Does setting requireMatchingUserAgentForSession to false have any additional implications to be aware of?

(Asked by: username_0 on 2016-03-04)

I recently ran into an issue that I was able to fix with what feels like a workaround – updating the config setting [requireMatchingUserAgentForSession](https://craftcms.com/docs/config-settings#requireMatchingUserAgentForSession) to `false`.

While I expect something changed on the website where I needed to do this, I'm not sure what would have changed and am curious if anybody with deeper knowledge of how user agents and sessions work could help explain what factors are at play here.

In my situation, members of the site were getting logged out shortly after they logged in and, while I could login to the control panel and navigate to several pages, each time I tried to access the Users tab, no users would display and I'd get logged out. Each time this happened the corresponding item in the logs referenced a discrepancy between the user agent in the cookie and the current user agent. The specific error message was:

> Tried to restore session from the the identity cookie, but the saved
> user agent (Mozilla/5.0 (Macintosh; Intel Mac OS X 10\_11\_3)
> AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109
> Safari/537.36) does not match the current userAgent (Mozilla/5.0
> (Macintosh; Intel Mac OS X 10\_11\_3) AppleWebKit/537.36 (KHTML, like
> Gecko) Chrome/48.0.2564.116 Safari/537.36).

The error outlines a discrepancy between `Chrome/48.0.2564.109` in the cookie vs the current `Chrome/48.0.2564.116`.

What scenario creates a discrepancy between the User Agent in the cookie and the current User Agent? What variables can change that cause a previously working membership site, to require suppressing differences in these variables to work? Does suppressing this required match and allowing for differences in the current User Agent and the session open up possibilities for other issues to arise?

**Tags:** users, error-message


---

## 1 answers

### Answer by username_1 on 2016-03-04. Score: 2

The reason Craft stores the user agent string in the authentication cookie when logging in is to help prevent session/cookie hijacking. If will validate that it is the same subsequent requests on the presumption if your cookie is hijacked, there's a significant chance that the browser that stole the cookie will have a different user agent string that the one the session was started with.

Granted, this isn't fool proof (user agent strings are easily spoofed) and some browsers store their version number (like you discovered) in the user agent string as well. This is all well-and-good until your browser decides to auto-update, forcing the string to change and then auto-logging you out of Craft, which looks like what you're seeing.


---

