When more than one instance of the application is running, users get stuck in an infinite login loop. This problem arises because session data (including user and MSAL tokens) is stored on the local filesystem of a single instance. When the load balancer directs a user to another instance, that instance doesn’t find the session data and treats the user as logged out, causing a redirect back to the login page.
Cause:
- The default configuration (
SESSION_TYPE = 'filesystem') saves session data locally to each instance. A user’s subsequent request might land on a different instance than the one holding their session info.
Proposed Solution:
-
Switch to a Shared Session Store
- Use Azure Cache for Redis with private endpoints to store session data.
- This ensures every instance reads from and writes to the same session store.
-
Configuration Steps:
- Provision an Azure Cache for Redis resource.
- Update the application’s
requirements.txt to include Flask-Session[redis] and redis>=4.0.0.
- Update the
config.py to set SESSION_TYPE = 'redis' and reference the Redis connection via environment variables (e.g., REDIS_HOST, REDIS_PORT, REDIS_PASSWORD, REDIS_SSL).
- Make sure the
SECRET_KEY is set consistently across all instances using environment variables in Azure App Service.
Acceptance Criteria:
- Users can successfully log in and remain logged in across all instances.
- No infinite login redirections when the app is scaled out to multiple instances.
- Application logs confirm that Redis-based session storage is active and functioning.
Implementation Plan:
- Create or Update Azure Cache for Redis
- Generate/Copy access keys from the portal.
- Enable private endpoints if desired for better security.
- Set Environment Variables in Azure
FLASK_SECRET_KEY, REDIS_HOST, REDIS_PORT, REDIS_PASSWORD, and REDIS_SSL.
- Update Application Code
- Include Redis-specific code in
config.py for session handling.
- Fallback to
filesystem in local dev/test scenarios if environment variables aren’t set.
- Test and Validate
- Deploy changes to a staging slot with multiple instances.
- Validate that the session remains intact across all instances.
When more than one instance of the application is running, users get stuck in an infinite login loop. This problem arises because session data (including user and MSAL tokens) is stored on the local filesystem of a single instance. When the load balancer directs a user to another instance, that instance doesn’t find the session data and treats the user as logged out, causing a redirect back to the login page.
Cause:
SESSION_TYPE = 'filesystem') saves session data locally to each instance. A user’s subsequent request might land on a different instance than the one holding their session info.Proposed Solution:
Switch to a Shared Session Store
Configuration Steps:
requirements.txtto includeFlask-Session[redis]andredis>=4.0.0.config.pyto setSESSION_TYPE = 'redis'and reference the Redis connection via environment variables (e.g.,REDIS_HOST,REDIS_PORT,REDIS_PASSWORD,REDIS_SSL).SECRET_KEYis set consistently across all instances using environment variables in Azure App Service.Acceptance Criteria:
Implementation Plan:
FLASK_SECRET_KEY,REDIS_HOST,REDIS_PORT,REDIS_PASSWORD, andREDIS_SSL.config.pyfor session handling.filesystemin local dev/test scenarios if environment variables aren’t set.