<p><strong>TL/DR</strong></p>

<p>It sounds like you need to enable sticky sessions at your load-balancer/router level, so that the users will be sent back to the same server in the cluster that their session originated on.</p>

<p><strong>The long version</strong></p>

<p>In Craft 2.x, every new user gets new <a href="https://secure.php.net/manual/en/book.session.php" rel="nofollow">PHP session</a> represented by a file on your web server and a cookie in your browser.  By default PHP names that cookie <code>PHPSESSID</code>, but Craft will default set it to <code>CraftSessionId</code>, although you can configure its name with the <a href="http://buildwithcraft.com/docs/config-settings#phpSessionName" rel="nofollow">phpSessionName</a> config setting.</p>

<p>PHP has a way to use <a href="https://secure.php.net/manual/en/session.configuration.php#ini.session.use-cookies" rel="nofollow">sessions without cookies</a> providing a way to append a unique session ID to the querystring of a URL, but (for many reasons), Craft doesn't support that method.</p>

<p>In addition to the PHP session cookie, Craft will create an identity cookie upon a successful login that has a randomly generated name similar to <code>4190d8c6874f8615f88325f5b285fc40</code>. That cookie is how Craft keeps track that you're successfully authenticated.</p>

<p>The problem with load-balanced setups that don't use sticky sessions is that with all of these default settings, when a session is started on server A and then a user is bounced to server B, server B has no knowledge of the session because it was created on server A.</p>

<p>There are ways around it, of course, the easiest being to enable stick sessions at the load balancer level, ensuring that users will get sent back to the server their session was started on for the lifetime of that session.</p>

<p>Alternatively, if sticky sessions aren't your thing, you can configured a shared network storage location and tell each web server to use it for its <a href="https://secure.php.net/manual/en/session.configuration.php#ini.session.save-path" rel="nofollow">session.save_path</a>, ensuring they all have access to all server-side session files.  If you go this route, you'll also want to set the <a href="http://buildwithcraft.com/docs/config-settings#appId" rel="nofollow">appId</a> config setting to be identical across all web servers, since it is used in decrypting cookie data (including sessions).  By default it it is randomly generated per Craft installation.</p>

CC BY-SA 3.0
2015-11-05T20:51:45.177Z
Thanks Brad. So it sounds like Craft admin uses server-side sessions but no replication is set up for it. Are there supported options for session replication or client-side cookie based sessions? Or is the session too big and requires file system access?
TheArchitect
CC BY-SA 3.0
2015-11-05T22:42:01.250Z
Updated with more info!
Brad Bell
CC BY-SA 3.0
2015-11-05T19:37:10.907Z
2015-11-05T22:41:51.330Z
2015-11-05T22:41:51.330Z
Brad Bell
<p>We're having a problem logging in the Craft admin tool @ <a href="https://www.clearlabs.com/admin" rel="nofollow">https://www.clearlabs.com/admin</a> when we have more than one server in the cluster.
After submitting credentials, Craft seems to keep 302-bouncing infinitely between <a href="https://www.clearlabs.com/admin/login" rel="nofollow">https://www.clearlabs.com/admin/login</a> and <a href="https://www.clearlabs.com/admin/dashboard" rel="nofollow">https://www.clearlabs.com/admin/dashboard</a>.
The few times we are able to log in, we seem to get kicked out of our session back into an infinite redirect loop.
Note this does not affect our website, but only the admin web app.</p>

<p>Upon review of the literature, we tried to set <code>overridePhpSessionLocation=false</code>, but it doesn't seem to help.</p>

<p>Can someone please confirm the configuration requirements for Craft clustering and/or give us some thoughts on what might be going on?
Thank you,
Cyril</p>

<redirect><login><authentication>
Craft admin login infinite redirect in cluster
# Craft admin login infinite redirect in cluster

(Asked by: username_0 on 2015-11-05)

We're having a problem logging in the Craft admin tool @ <https://www.clearlabs.com/admin> when we have more than one server in the cluster.
After submitting credentials, Craft seems to keep 302-bouncing infinitely between <https://www.clearlabs.com/admin/login> and <https://www.clearlabs.com/admin/dashboard>.
The few times we are able to log in, we seem to get kicked out of our session back into an infinite redirect loop.
Note this does not affect our website, but only the admin web app.

Upon review of the literature, we tried to set `overridePhpSessionLocation=false`, but it doesn't seem to help.

Can someone please confirm the configuration requirements for Craft clustering and/or give us some thoughts on what might be going on?
Thank you,
Cyril

**Tags:** redirect, login, authentication


---

## 1 answers

### Answer by username_1 on 2015-11-05. Score: 2 | Accepted answer

**TL/DR**

It sounds like you need to enable sticky sessions at your load-balancer/router level, so that the users will be sent back to the same server in the cluster that their session originated on.

**The long version**

In Craft 2.x, every new user gets new [PHP session](https://secure.php.net/manual/en/book.session.php) represented by a file on your web server and a cookie in your browser. By default PHP names that cookie `PHPSESSID`, but Craft will default set it to `CraftSessionId`, although you can configure its name with the [phpSessionName](http://buildwithcraft.com/docs/config-settings#phpSessionName) config setting.

PHP has a way to use [sessions without cookies](https://secure.php.net/manual/en/session.configuration.php#ini.session.use-cookies) providing a way to append a unique session ID to the querystring of a URL, but (for many reasons), Craft doesn't support that method.

In addition to the PHP session cookie, Craft will create an identity cookie upon a successful login that has a randomly generated name similar to `4190d8c6874f8615f88325f5b285fc40`. That cookie is how Craft keeps track that you're successfully authenticated.

The problem with load-balanced setups that don't use sticky sessions is that with all of these default settings, when a session is started on server A and then a user is bounced to server B, server B has no knowledge of the session because it was created on server A.

There are ways around it, of course, the easiest being to enable stick sessions at the load balancer level, ensuring that users will get sent back to the server their session was started on for the lifetime of that session.

Alternatively, if sticky sessions aren't your thing, you can configured a shared network storage location and tell each web server to use it for its [session.save\_path](https://secure.php.net/manual/en/session.configuration.php#ini.session.save-path), ensuring they all have access to all server-side session files. If you go this route, you'll also want to set the [appId](http://buildwithcraft.com/docs/config-settings#appId) config setting to be identical across all web servers, since it is used in decrypting cookie data (including sessions). By default it it is randomly generated per Craft installation.

> **Comments:**
> **username_0**: Thanks Brad. So it sounds like Craft admin uses server-side sessions but no replication is set up for it. Are there supported options for session replication or client-side cookie based sessions? Or is the session too big and requires file system access?  
> **username_1**: Updated with more info!  

---

