Dead websockets connections don't reconnect when the app is behind an auth proxy

[nirben82]

When leaving a Mesop application open for a long period (e.g., overnight) in a corporate environment behind a proxy with Single Sign-On (SSO), the WebSocket connection eventually drops due to session expiry.

When the app attempts to reconnect or send a message:

1. The corporate proxy intercepts the request, sees that the auth cookie has expired, and attempts to return an HTTP 302 Redirect to send the user to the SSO login page.
2. The browser's native WebSocket API does not follow HTTP redirects. If a WebSocket handshake receives anything other than a 101 Switching Protocols response, it immediately aborts.
3. For security reasons, the browser does not expose the HTTP status code or location headers of the failed handshake to JavaScript; it just throws a generic, opaque WebSocket error: Event {isTrusted: true, type: 'error'}.
4. This leaves the app in a disconnected state without informing the user or allowing them to re-authenticate.

[richard-to]

A thanks for posting this. For some reason I thought this issue was resolved by one of the previous websocket patches.

[richard-to]

I added a temporary patch here: #1390

Do you think that would help resolve the issue in a way that is reasonable UX? Long term I'd like to improve Mesop's handling for network errors and error cases in a more robust way. But want to resolve your use case first.

Right now what will happen is once it detects the SSO redirect it will redirect in the same tab and then I think once you login in it should redirect the user back (need to verify that). iirc you're able to retrieve the existing state already.

[nirben82]

It's fine, we decided that I would send you a pull request with the solution, I only got to it now and then realized that there is no bug open. I tried out this solution on my dev app, over night, the result was that I was displayed with the Google auth page (not the SSO page, an additional OAuth2.0 flow I have afterwards) for some of the tabs that I left open and then redirected back to the same page that was open. I am actually not sure why I was redirected to the Google OAuth page. I need to check it out again, will update.

Since I didn't know you are working on a solution I also created one myself, it different and provides the user with the control by firing an event which can be caught by the user in a custom javascript with a web component. On my side, I display a message to the user asking it to click in order to open a new window that does the SSO and closes (just following how its usually done in other apps in google). WDYT? main...nirben82:mesop:fix_1389

[richard-to]

Ah yeah that's interesting about how it redirected you to a different auth page than expected. All my change does is force a page reload so it's not provider specific.

I like that your solution gives the user a way to manually handle expired session. Feel free to post a PR and I can look into it more closely, But on first skim, it sounds mostly reasonable and it seems generic enough.

[richard-to]

Ok, I'm pushing this change to pip as 1.3.0rc2. Once you've tested it, I can create 1.3.0

[nirben82]

Tested 1.3.0rc2 in CloudRun for the above functionality and regular happy flow. Works well. Thanks!

[richard-to]

Thanks for verifying. I've added 1.3.0 to pypi