Accessing cookies in Phoenix.Socket connect

I am extremely sorry to revive this extremely old thread, but I am trying to access a cookies in a socket connection, and unable to, I posted by entire setup here (How to use Phoenix `socket` on localhost with React Frontend?)

I would really appreciate if someone could point me to where I messed up

Does it also applies to socket auth? I didn’t yet research current docs for phx.gen.auth, but stumbled upon this thread stating that no cookies can be used for auth in sockets, while I hoped to use server-stored sessions with cookies for socket auth (as well as for regular auth). I will research the post you mentioned as well as the docs

You can already access session cookie data as seen in the post before yours.

Generally SameSite is only a layer of defence. E.g. it depends on all your subdomains for a given root domain (based on https://publicsuffix.org/) to be save to provide security.

Take a loot at phx.gen.auth. It has all the pieces needed to implement that.

SameSite looks available to browsers for quite some time. Does it change situation regarding the possibility of optionally using cookies for authentification in websockets? (even as web-specific option not available for possible custom transports)

Also, how could banning the user be implemented when using a token-based socket authentification? It looks to be problematic

We can get access to the user_token natively by copying LiveView’s approach (CSRF):

# lib/web/endpoint.ex
@session_options [ ... ]

socket "/socket", Web.UserSocket, websocket: [connect_info: [{:session, @session_options}]]

// assets/app.js
let csrf_token = /* get via `csrf_meta_tag()` or `csrf_token_value()` */
let socket = new Socket("/socket", {params: {_csrf_token: csrf_token}});

# lib/web/channels/user_socket.ex
def connect(_params, socket, %{session: session}) do
  if user_token = Map.get(session, "user_token") do
    user = Account.get_user_by_session_token(user_token)
    {:ok, assign(socket, :user, user)}
  else
    :error
  end
end

Exactly my point, hence why it should be stored in the cookie.

For example, for what JWT is designed for.

I’ve carefully read all the concerns about security (I agree with), BUT I think you are just considering scenarios in which the same Phoenix backend is both the authentication service AND the websocket endpoint.

I want to suggest you another scenario, for which the suggested workaround of using a csrf token from the Phoenix backend won’t be possible.

Let’s say we have these services:

A - login.somesite.com: Ruby on Rails (or whatever you prefer) backend that has the responsibility to Authenticate user (= to return a jwt token, in response to a login request, through a HttpOnly, secure, SameSite strict)
B - www.somesite.com: another (micro)service that renders tha app and manges the Business logics.
C - communications.somesite.com: the Phoenix (micro)service that handles WS Communications.

If you prefer, B & C might be the same service, no matter.

Service A sends a signed JWT HttpOnly cookie on domain “.somesite.com”, so that each services can exploit a decentralized authentication / verification, without the need of asking A (of course, that’s the way JWT has been designed for).
The wss protocol used to open a bidirectional channel, as you pointed out, allow us to send that jwt cookie to the C service (Phoenix) too, without the need to make the jwt accessible to the JS (it would open a way more dangerous security problem, if we woudn’t have that cookie “HttpOnly”).

Here, unfortunatly, comes the Phoenix backend with its design choices, that prevent us from reading that cookie (that wss protocol would let us send), making it useless.

I agree with the concerns that having a secure first design approach is in general a good choice, but in this case:

• Developer has one secure way to prevent the security risk (CSWSH), simply by enforcing the Origin checks on server side.
• Developer has no way to access the cookie, since the framework has chosen to deny its access.

I would have prefered - in these cases - a “smart config” approach, if you care so much about CSWSH risk, where developers can - through an opt-in choice in server configuration - choose to have the cookie available in the connection endpoint.

What do you think about?

The best explanation is here:

https://medium.com/coletiv-stories/using-websockets-with-cookie-based-authentication-7e4bb9262898

pretty much what I meant as well

You aren’t allowed to control the origin header from inside the web browser sandbox as per the standard, hence why a web browser javascript library doesn’t expose such an option.

The origin header is to control web browser security, if you are in native code then you could easily just scrape a webpage to get a token (potentially even grabbing the web browsers cookie or whatever else) and then feed that in to the live websocket, so none of that security matters anyway for native code (hence why you should build a proper auth system if you need auth regardless, but the browser should be able to store that auth in a cookie backed by an origin as that is the way the standard was written).

Hm, I used React Native with Phoenix Socket library (technically not a native ws lib) and didn’t see such an option, here are the ones the can be specified phoenix_socket/dist/socket.js at master · mspanc/phoenix_socket · GitHub maybe it would work as a key in params?

Anyway the way I see it is an origin that we can freely control can also be controlled by a malicious 3rd party so it doesn’t add much in terms of security.