Describe how authentication should be handled

[benmccann]

Describe the change

I'm not super familiar with web sockets and am not sure if crossws might have any of its own requirements.

If you want a secure connection do you use wss:// and then return the response from handleUpgrade if the user is authenticated and there's an upgrade header and a 403 response if not authenticated even when there's an upgrade header?

URLs

No response

Additional information

• Would you be willing to help?

[LukeHagar]

I also would appreciate some more detail on the flow mentioned here.

What exactly is the difference in intention between returning a response or just the headers of a response?
Is returning a Response intended to always abort the upgrade request? What if the response is a 101?

Personally I think a more explicit accept() or upgrade() combined with an explicit reject() or abort() to specify the action being taken in the upgrade handler would be much easier for most people to understand.

For context I am currently exploring integrating native WebSocket support into SvelteKit, and this package seems to be a pretty fantastic fit.

[LukeHagar]

Even if accept(), upgrade(), reject(), or abort() are all just wrappers for creating and returning a response or headers

[pi0]

Some improvements in 0.3.2 should help this.

Let's make an example in docs for simple session/auth handling. (PR is more than welcome if anyone is interested in helping!)

[sandros94]

Some improvements in 0.3.2 should help this.

Let's make an example in docs for simple session/auth handling. (PR is more than welcome if anyone is interested in helping!)

I'm happy to help.
By simple session/auth you mean using h3 utils (I see unjs/h3#960 is being worked on), or any generic example?

Do I understand it correctly? (I'm having doubts on the first step)

1. during upgrade we evaluate if session/auth is valid or not. If it is we return stuff that can be accessed by other hooks
2. the other hooks access that data for later use

P.S.: I'm rereading the latest changes, as I might have missed some logic

EDIT:
also, I see the volatile note about context

context data can be volatile in some runtimes.

does it mean between hooks or something else?

[pi0]

I think for crossws we can use a simple example using standard request and headers to check something like basic auth or a cookie. When auth fails, we throw a Response.

If not fails, we can (optionally) return some headers, mainly usable for setting a cookie but perhaps we can just use a comment to say it is possible.

Shared context can be modified from request.context in upgrade and access/update from peer.context.

Context could be volatile in clousflare durable only. It can be useful for things like caching a computation (h3 session for example is cached in context)

I think we could have two examples for auth and context, if you have some ideas feel free to open a draft i can help from there!