Phoenix: Suggestion: Add Set-Cookie header to the connect_info

[lachezar]

Since Phoenix 1.4 introduced connect/3 in the UserSocket module, which carries as a third parameter connect_info with all set "x-" headers during the connection, I would suggest extending this functionality and adding either all headers to the connect_info or at least the "Set-Cookie" header besides the "x-" headers.

The cookie header could be useful source of authentication/authorization details, that would be passed naturally when an http update request is performed, but the Phoenix framework obscures this information at the moment.

To summarize, my suggestion is to add :cookies stub in the case-statement in connect_info function. I would like to hear other opinions before trying to make a PR for this, since it feels like a major architectural change that I don't feel confident doing entirely on my own, also it seems there was such PR 3 years ago #621.

[chrismccord]

We explicitly avoided regular headers so folks wouldn't grab cookies :D

The tldr; is cross-site websocket hijacking is the concern (https://www.christian-schneider.net/CrossSiteWebSocketHijacking.html). WebSockets do not respect same origin policy so this is an attack vector we want to prevent. We have Phoenix.Token for authentication/authorization details, which is the preferred approach especially because it works for all transports. Thanks!

[jclem]

@chrismccord I'm not super comfortable having the authentication token available in the client. In fact, I think the inability to use cookies for authentication causes even more confusion around security: A number of times, I've had it suggested to me to solve this by keeping the token in a non-HTTP-only cookie if I don't want to expose the token to the client (in which case it's still exposed in document.cookie).

For a few apps I've built, it would be significantly more secure to continue to use cookies for socket authentication paired with an Origin check. Is there something I'm missing in my assumption that just having a strict Origin check would mitigate the cross-origin WebSocket hijacking concern completely?

Update This was resolved on Slack as far as I'm concerned. I respect the decision to only support tokens 👍 , just wanted to voice an alternative opinion.