Open sharma-manish opened 3 years ago
Hi sharma-manish - thanks for reaching out.
Why do you think it requires session stickiness? The key-value-store used should be in sync with all cluster nodes. So that given it doesn't matter on which instance you request will be processed. Does this make sense?
For more information about cluster state snyc see the following link: https://docs.nginx.com/nginx/admin-guide/high-availability/zone_sync/
Lets assume you have a 5 node cluster spread across different data centres for HA and DR. The key value store can be "synced" across cluster nodes, but it is going to have some latency. Lets say your web page embeds various widgets which execute several REST calls to the backend, AND your backend is configured for "round robin" load balancing, so first 5 REST calls will potentially land on different Nginx nodes. And since browsers typically send several requests in parallel, you might see login process being triggered for some of the requests.
We have tried running our application without session stickiness and observed these issues. We were then told to enable session stickiness to work around this.
I understand your point. So the request would be to be able to turn the opaque cookie on and off. So the access_token will be send as a cookie instead of the opaque session reference?
The OIDC plugin requires session stickiness to be enabled in case of highly available deployment topology. This is an anti pattern. Can something be done for removing this dependency?
Browsers typically send request for multiple resources for a site in parallel. In a multi node deployment with round robin load balancing algorithm, the login process can potentially get triggered for multiple requests.