Cookie based authentication for websocket connections

[phanimahesh]

Is it possible to authenticate websocket connections from the cookie in initial HTTP Upgrade request? I haven't found any simple way to do it.

[emqplus]

@phanimahesh, this is a good idea:) Do your write Erlang? Please read emqttd_ws_client.erl that the module could get cookie from HTTP Upgrade request

[phanimahesh]

I am working in elixir but can read erlang. I have read emqttd_ws_client.erl and can patch it to extract the cookies. However, I am not entirely sure of how to pass this on to the auth plugins.

Should the mqtt_client record be updated? What would be the cleanest way to do this?

[phanimahesh]

@Erylee I need some suggestions:

• Should a new user defined function be allowed to extract username and password using any arbitrary roles? Or
• Should new configuration values be added to allow mapping cookie keys to username and password?

What about whitelisting allowed origins for websocket connections, either by using a CORS header or otherwise?

[emqplus]

@phanimahesh, If I add a 'cookie' field to 'mqtt_user' record, will it work for your project?

[phanimahesh]

Do you mean mqtt_client?

If the cookie is available in the auth plugin hook in any way, it works for our project.

If you are planning on modifying any of the records, it may be a better idea to pass on all headers as a map or proplist. If someone uses custom headers or let's say http basic auth, this will cover all such scenarios.

We need this asap, and are planning to do it ourselves tomorrow. We can send a pull request for this tomorrow if it is okay with you.

[emqplus]

@phanimahesh, I create a branch for this issue:) and submit a quick fix. Please check it now.

Branch: https://github.com/emqtt/emqttd/tree/issue%23231

Commit: bb02ced

[phanimahesh]

Looks great!

However, I think including a full list of headers is a good idea. What if someone later wants to authorize using bearer tokens or basic auth?

I was thinking along the lines of

Headers = mochiweb_request:get(headers,Req),
Header_list = mochiweb_headers:to_list(Headers),
ProtoState = emqttd_protocol:init(Peername, SendFun, [{ws_initial_headers, Header_list}|PktOpts]),

in mqtt_ws_client.erl and corresponding changes elsewhere. What do you think?

[phanimahesh]

@Erylee: Can you have a look at #240 ?

[emqplus]

@phanimahesh, It's awesome:) I merge the pull request to 0.10.0 release. Thanks.

[phanimahesh]

Thanks! :)

[phanimahesh]

@emqplus This is no longer possible with emqx3.0. Was it removed intentionally or accidentally? Will you accept a PR adding it back?

[gilbertwong96]

@phanimahesh Sorry, because we have migrated webserver from mochiweb to cowboy, so it was removed accidentally. Welcome for your PR !

[gilbertwong96]

This feature has been implemented in emqx 3.1-rc.2.

[dufourc]

Hey I read @phanimahesh PR and from what I understood, the headers has been added into the ClientInfo therefore the cookies are in the ClientInfo as well. But where is it used concretely? How can I use it with the different auth plugins?

If I read the emqx-auth-http docs, I can't see the headers, neither cookies as params. I went further and I tried to read the erlang code with my really basic understanding of it. I think it the params could be added here https://github.com/emqx/emqx-auth-http/blob/master/src/emqx_auth_http_cli.erl#L78 adding a line in the map to pass the sessionId (the name could be specified in the config). Or maybe forward the cookies?

I saw as well a feature request here: #2676. @gilbertwong96 What where you thinking to do for emqx_auth_cookie? Would it check if the session_id is present in a certain table (SQL request) or make an HTTP call?

In this page(https://docs.emqx.io/broker/latest/en/introduction/checklist.html) I can see 'Browser cookie authentication'.

I'm sorry but I'm a bit confused if this is possible to achieve or not and how.

I'm happy to contribute but I might need some guidance to decide where and how to implement it.

[HJianBo]

Hi @dufourc These discussions may be out of date. I have transfer this comment to a New issue : #3747

[dufourc]

Hey @HJianBo thanks! I think, you're right, it might be better to create another issue
When I wrote the comment I was really confused. After it, I realised that this issue here was to have access to the cookies/headers from the ClientInfo to be able to use it in a plugin. And that @phanimahesh has probably developed his own plugin to use it.