fix(auth): surface 401 session expiry to frontend with user notification

[ayushshukla1807]

Fixes the session dropping issue mentioned in #116.

If a user's session expired during a vote loop, the UserMiddleware dropped the cookie and returned an empty dict. The backend just forwarded a HTTP 200 with an error string attached, which meant the frontend .catch() block never triggered. The UI would move on like normal while the vote was lost.

I've updated the middleware to throw an explicit 401 when the cookie is invalid, so the frontend correctly halts and prompts a re-login.

[userAdityaa]

Have you tested the application flow manually?

Previously, when cookies were invalid or unknown, the middleware returned an empty dictionary, which Clastic/MessageMiddleware interpreted as a silent 200 OK response. With your changes, those same scenarios now return {'_status_code': 401}, causing Axios to treat the response as a failure and the frontend to surface a 401 error.

more changes will be required, please check this whole flow manually.

[userAdityaa]

Sorry, but this comment doesn’t seem relevant to the actual fix.

[ayushshukla1807]

Thanks for pointing that out, Aditya.

I've cleaned up the code by removing the redundant comments.

I also followed up on your suggestion to check the whole flow: I've updated all authentication failure paths in the middleware to return 401 (including missing cookies and unknown IDs) and added a global interceptor in the frontend to handle these cases gracefully.

This ensures that if a session drops mid-view, the app will now redirect back to home for a re-auth check instead of hanging or showing empty templates.

I've verified this behavior by simulating cookie drops locally.

[lgelauff]

Thanks for working on this. There's a related closed PR — #472 by @userAdityaa — that covered the same ground. It's worth reading both for how it surfaces the error message to the user and for
#472 (review).
A few concrete observations:
- The 401 intercept is added inside addInterceptors, which is called on both apiBackend and apiCommons. Please consider if this could result in side effects.

• window.location.href = '#/' redirects silently with no message. Wouldn't that mean that the user loses in-progress work without knowing why? The backend already appends the error text to response_dict['errors'] — that could be shown before any redirect, or instead of one.
• The third hunk in mw/init.py (the su_to branch) is a superuser impersonation misconfiguration, not a session expiry. Returning 401 there conflates two distinct failure modes and seems outside the scope of Save Changes sometimes does nothing #116. Please reflect.

[ayushshukla1807]

Thanks for the detailed review, @lgelauff — and for pointing to #472. I have addressed all three points:

1. Interceptor scope — Split into addLoadingInterceptors() (applied to both apiBackend and apiCommons) and a separate addAuthInterceptor() applied only to apiBackend. Commons API 401s are not Montage session failures and will no longer trigger a redirect.

2. Silent redirect — The interceptor now reads error.response.data.errors[0] — the text the backend already appends to response_dict['errors'] — so users see the actual failure reason (e.g. 'invalid cookie userid, try logging in again') before any navigation. The 2-second delay gives them time to read it.

3. su_to branch — Already returning 400 to distinguish superuser impersonation misconfiguration from session expiry. No change needed and I agree the distinction is correct.

Updated in the latest commit on this branch.