WebSockets Next: provide strategies to process unhandled failures

[mkouba]

Description

Right now, we log an error message when a unhandled failure occurs (unless it's a "WebSocket closed" error in which case we only log a debug message).

It seems reasonable to provide several strategies instead:

1. Close the connection (default)
2. Log an error message
3. NOOP

[sberyozkin]

It would nice to have an option to redirect a user to a configured page once the connection is closed

[mkouba]

It would nice to have an option to redirect a user to a configured page once the connection is closed

I don't think that's possible. There's no HTTP response once the upgrade is finished. We could use a specific close reason though.

[mkouba]

It would nice to have an option to redirect a user to a configured page once the connection is closed

I don't think that's possible. There's no HTTP response once the upgrade is finished. We could use a specific close reason though.

I mean not possible after the upgrade but it should be possible if we detect a problem during the handshake, e.g. once we implement #40622.

However, this issue is more generic, not specifically related to security.

[sberyozkin]

I mean not possible after the upgrade but it should be possible if we detect a problem during the handshake, e.g. once we implement #40622.

Sure

[michalvavrik]

1. Close the connection (default)
2. Log an error message
3. NOOP

That would be very helpful. But there is a question: Ideally @Authenticated and @RolesAllowed are just user-friendly alternatives to path-matching HTTP Security policies (perms). So if the authenticated policy is performed eagerly and returns 401, we should be able to perform security checks for security annotations applied on the @OnOpen (either by method level or inherited from the class level) and perform it eagerly as well. So we would return 401 and we wouldn't call @OnError as the WS connection has never been established. We authenticate the initial HTTP request, not WS connection.

WDYT?

[michalvavrik]

BTW I realize this issue is not security specific, it applies for other failures as well, but I hope the question is still valid.

[michalvavrik]

I mean not possible after the upgrade but it should be possible if we detect a problem during the handshake, e.g. once we implement #40622.

maybe I should had commented on #40622, apologies.

[mkouba]

I mean not possible after the upgrade but it should be possible if we detect a problem during the handshake, e.g. once we implement #40622.

maybe I should had commented on #40622, apologies.

No problem. Speaking of "eagerly performed @OnOpen" - I'm afraid that this would complicate the workflow a lot. So I think that we should rather consider the case where security annotations are declared on the endpoint class and applied before the endpoint instance is actually created.

[michalvavrik]

I mean not possible after the upgrade but it should be possible if we detect a problem during the handshake, e.g. once we implement #40622.

maybe I should had commented on #40622, apologies.

No problem. Speaking of "eagerly performed @OnOpen" - I'm afraid that this would complicate the workflow a lot. So I think that we should rather consider the case where security annotations are declared on the endpoint class and applied before the endpoint instance is actually created.

Sounds acceptable. We can collect feedback from others. Personally I think if it is highlighted in docs it will be useful feature. Thank you