Menu
▾
▴
#35 filelocker cookie unable to be used to manage lb persistence
Something interesting we have observed with multiple filelocker instances behind a reverse proxy:
- We were using filelocker's cookie as a means to track persistence on our f5 + session.storage_type was ram
- 4 nodes up, we universally hit an infinite redirection loop when we would logout, then click the banner in the top-left (slash); was true in Chrome, FFox, etc
- Only way to overcome was to remove the filelocker cookie in browser prefs (no combination of closing browser, CAS logging in/out, etc would resolve)
- Dropped to one node, no issues encountered like this.
- Dropped to two nodes + reverse proxy set to list X-Node-Addr headers to let clients know which node they were hitting
- Headers appear you infinite redirect when bounce to same node
- Headers also show new cookie set after logout (existing cookie expiry set to current time upon logout yet gets for js/css set new session/cookie)
We were able to overcome via either setting source address as a backup means of persistence (which was problematic for lots of proxies/NATed clients) or have the reverse proxy ignore the filelocker cookie/source addr and set a cookie itself for tracking. That resolved the inf redir loop issue.
Filelocker 2.4.1
If you are using an F5/load balanced environment you'll need to use db sessions so that all members of the cluster have access to the same session information.
We finally have a load balanced environment to test in (fairly similar to the one you're running it sounds like, F5's in front). So hopefully we can test things a little better for these scenarios.