Confirm AcceptOrigins API

[nhooyr]

I think it's a little awkward and inflexible. Maybe its better to have devs verify the origin themselves if its not equal to r.Host and then pass an option like websocket.AcceptInsecureOrigin()

[nhooyr]

I don't want people to have to parse Origin themselves and compare. I feel like they'd just give up due to the boilerplate and pass websocket.AcceptInsecureOrigin().

[nhooyr]

Todo open new issue about adding acceptinsecureorigin option

[nhooyr]

their code would be something like parsing the Origin header and then comparing the host of the origin header against some validated domains.

https://github.com/nhooyr/websocket/blob/932d16d09e7fe18f3c0fbd80c67324d43765a974/accept.go#L175

my concern is that during a refactoring, it'd be really easy to move around code and then miss this critical security check.

[nhooyr]

Or they don't realize they need to do a url.Parse and do something like strings.Contains which enables a CSRF attack I think.

[nhooyr]

Another option is to make AcceptOrigin take a closure that takes the origin header and returns a boolean if the origin header is ok, similar to gorilla/websocket. I think that'd be pretty reasonable tbh. Would be really simple code. I'd also have to make sure to always strings.LowerCase the domain though so its easy for them to just use HasSuffix or == and not EqualFold.

[nhooyr]

Thats definitely the move.

[nhooyr]

Though, I can't really see a case where someone wants to accept origins that aren't just a list of domains.

[nhooyr]

Another issue I have with the current API is that it's hard to fully disable origin validation as you'll have to parse the domain out of the origin header and pass it to AcceptOrigins or remove the Origin header from the *http.Request which I suppose is reasonable but janky and *http.Request is documented to not ever be modified by handlers.

[nhooyr]

I think I just add a AcceptInsecureOrigin option to disable validation and panic if both AcceptOrigins and AcceptInsecureOrigin are passed.

[nhooyr]

There are three situations

1. You want to dial cross origin and have cookies be sent
2. You want to dial cross origin and send auth via a query parameter or via a ws message
3. You want to dial cross origin and not send auth

I don't think 1 is very common. I think 2 and 3 are far more common because 2 gives auth control to the dialing javascript and 3 allows public cross origin WebSocket servers.

I cannot think of a good scenario in which 1 would be used so I'm going to remove AcceptOrigins for now and just add AcceptInsecureOrigin which I think will work better as it targets the common cases.