On setting headers?

[adwelly]

I am trying to establish a websocket connection where authorization is controlled by an encrypted bearer token available on the client side. This is normally handled by setting an 'Authorization' header in the request.

As far as I can see this is handled in the clojurescript side make-channel-socket! function by passing this
in the :ajax-opts map, and looking through the encore library it seems to need the :headers keyword. So I've written:

(let [response (make-channel-socket! "/websocket"
{:type :auto
:ajax-opts {:headers {"Authorization" "my-token"}}})]
....)

The server is claiming that this is not setting the Authorization header, and in fact when I look at the headers that come over with the request on the server side I can see that it's not being set.

What am I doing wrong here ?

[adwelly]

Some digging around and discussions with others has lead me to this page in Stack Overflow:

http://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api

The upshot of which is that the Websocket standard itself prevents this. It's a fairly old comment but it would explain what I'm seeing (assuming I got the make-channel-socket! call above correct).

[rboyd]

@adwelly have you settled on a workaround here? I have the same issue. Maybe the token can be sent in-band upon connect and the server drops other messages until the socket can be authenticated. It's a shame because we obviously lose the ability to do it in ring middleware (e.g. buddy-auth).

[ptaoussanis]

Hi there,

Sorry, don't have much time to dig into this atm. Have you tried using the :params opt to the client-side make-channel-socket!? That should let you easily communicate arbitrary data (e.g. auth data) to the server.

[danielcompton]

We pass auth data over URL params. I'm not in love with that solution, but there's not a lot of options when dealing with websockets. IIRC when web sockets are created, they make an HTTP request which is then upgraded to a web socket. Unfortunately you can't pass data over that initial HTTP request (as you've discovered).

[adwelly]

We are going to secure the websockets by allowing a connection to be made
by anyone, but will only start communicating from the server if the client
can then present credentials via the websocket within a certain time.

Not ideal, but the best I could think of under the circumstances.

On Thu, Oct 15, 2015 at 10:31 AM, Robert Boyd notifications@github.com
wrote:

@adwelly https://github.com/adwelly have you settled on a workaround
here? I have the same issue. Maybe the token can be sent in-band upon
connect and the server drops other messages until the socket can be
authenticated. It's a shame because we obviously lose the ability to do it
in ring middleware (e.g. buddy-auth).

—
Reply to this email directly or view it on GitHub
#173 (comment).

[rboyd]

Should work for me. Thanks guys. Really fine work with sente.

[Frozenlock]

@rboyd @adwelly

I think I found a way to use tokens with buddy-auth and sente.

Instead of using the authorization header, we store the token inside a cookie.
When the connection is first initiated, the buddy-middleware will check the token and insert the :identity in the ring-request.

(Here is a simple implementation of the jws cookie backend: https://gist.github.com/Frozenlock/c53b388cab3f639e0ff4)

You get stateless authentication via the token AND the :identity field is available in your sente event handlers with the ring-req argument. In those event handlers, you can drop any request made by a non-authenticated/authorized client.

[ptaoussanis]

Hi all, assuming this is resolved but please feel free to reopen if you're still having trouble.