7

We have a Drupal application that uses sso to log users in.

We are using AWS classic load balancers (ELB), AWS is telling us that there is no session persistence on the ELB.

What I am trying to figure out is how cookies work with non persistence on the classic load balancers.

example.com DNS is pointed to the ELB. There are 2 servers in the pool Server1 and Server2

What we want to happen is if a user hits their home page on http://example.com/user/12345/ say on server 1 if they are not logged in already they are redirected to the sso page http://example.com/user/login/sso, automatically log in and get a cookie SESS<hexnumber> and then redirected back to http://example.com/user/12345/

We are not allowed to add any sessions server (redis) what is the guarantee that they will stay on server 1 for both of the redirects.

To my knowledge with every hit to 'example.com' the user could end up on either server 1 or server 2.

My Question:

If they get the cookie on server1 and then are redirected to server2 how will server2 know that a cookie is already assigned to that user on server1?

I seem to be thinking myself in circles. When working on this type of setup in the past using LBs without session persistence we used a redis server to hold the sessions and each request would look at the redis sever for the session information.

chris
  • 3,933
  • 6
  • 26
  • 35
Donna Delour
  • 414
  • 5
  • 10

2 Answers2

3

A cookie is set in the browser, not in a server. It is restricted to a domain and, optionally, a specific path in the URL, so as long as both servers are accessed by the same domain, the cookie will be there.

If a cookie points to a session, then it is necessary that both server1 and server2 have access to that session in some way. If sessions cannot be shared between the servers then you need to force a user to persist to a specific server. This can be easily accomplished with DNS and alittle bit of URL rewrite magic:

  • www.example.com points to both servers.
  • www1.example.com points only to server1
  • www2.example.com points only to server2

Using a set of simple(ish) rewrite rules and a cookie, the user can then be locked to a particular server, ensuring that the his session persists.

Here are some more details.

DNS:

  • example.com A 1.1.1.1, A 2.2.2.2
  • www.example.com CNAME example.com
  • www1.example.com A 1.1.1.1
  • www2.example.com A 2.2.2.2

Rewrite rules:

  • persistence cookie: "backend"
  • initial connection: "backend" not defined, set "backend" to www1 or www2, depending on which server has answered and redirect to that server. The cookie must be set to domain "example.com", this way it will be loaded on both www1 and www2
  • If "backend" is defined, ensure that its value matches the server instance and redirect if necessary.
  • Ensure that the session cookie is defined in the full domain name of the server - that is www1.example.com or www2.example.com

The rewrite logic is to be defined in the web server itself. All modern web servers have very featureful rewrite languages that are totally capable of implementing this functionality.

  • I have thought about the example1.com and example2.com however I am not allowed to tell a user they have to use example1.com or example2.com this was thought up without a clear understanding on how cookies and browsers work, so in trying to save face making some sort of back end magic happen. How can I use `example.com` if the users gets a cookie then keep them on www1.example.com or www2.example.com? – Donna Delour Oct 17 '18 at 14:28
  • I updated my answer –  Oct 17 '18 at 14:38
0

If you cannot use a session management database like Elasticache Redis(Redis for just sessions shouldn't cost more than $15 per month), then the next best option is to enable sticky sessions on the ELB;

https://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html

This will force users to goto the same the same backend node throughout the session. A "load balancer generated cookie" with a lifetime of 900 seconds should be good enough but you can tweak this.

Jared
  • 21
  • 1