Skip to content

Add support for cookie based authentication in the initial handshake #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
ctradu wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Add support for cookie based authentication in the initial handshake #4

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b17e86e
Add support for cookie based authentication in the initial handshake
May 23, 2014
c4b4a77
Add support for continue frames in the begin message
May 30, 2014
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 20 additions & 1 deletion src/wsock_handshake.erl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@
-module(wsock_handshake).
-include("wsock.hrl").

-export([open/3, handle_response/2]).
-export([open/3, open/4, handle_response/2]).
-export([handle_open/1, response/1]).

-define(VERSION, 13).
Expand Down Expand Up @@ -83,6 +83,25 @@ open(Resource, Host, Port) ->
{ok, #handshake{ version = ?VERSION, type = open, message = Message}}.


-spec open(Resource ::string(), Host ::string(), Port::integer(), Cookie::string()) -> {ok, #handshake{}}.
open(Resource, Host, Port, Cookie) when is_integer(Port) ->
RequestLine = [
{method, "GET"},
{version, "1.1"},
{resource, Resource}
],

Headers =[
{"Host", lists:flatten([Host, ":", integer_to_list(Port)])},
{"Upgrade", "websocket"},
{"Connection", "upgrade"},
{"Sec-Websocket-Key", wsock_key:generate()},
{"Sec-Websocket-Version", integer_to_list(?VERSION)},
{"Cookie", Cookie}
],
Message = wsock_http:build(request, RequestLine, Headers),
{ok, #handshake{ version = ?VERSION, type = open, message = Message}}.

%=======================
% INTERNAL FUNCTIONS
%=======================
Expand Down
4 changes: 3 additions & 1 deletion src/wsock_message.erl
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@
%%========================================
%% Types
%%========================================
-type message_type() :: begin_message | continue_message.
-type message_type() :: begin_message | continue_message | continue.

% @type decode_options() = masked.
% @type encode_options() = mask.
Expand Down Expand Up @@ -357,6 +357,8 @@ process_frame(open_close, _, Frame, Message) ->
frame_to_complete_message(Frame, Message);
process_frame(open_continue, _, Frame, Message) ->
frame_for_fragmented_message(Frame, Message);
process_frame(continue, begin_message, Frame, Message) ->
Copy link
Owner

@madtrick madtrick Feb 2, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ctradu hi. I know it has been a long time since you opened this pull request but now that I'm back I would like to know the reasoning behind this change.

How could you have a Frame that's supposed to continue (be part of an ongoing message) and at the same time consider it as part of a new message?

Copy link
Author

@ctradu ctradu Mar 6, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@madtrick Hello. It has been a long time since I needed those changes also.
I know I've written a websocket client using wsock and igel and I know that I've made some changes so that I could authenticate using a http cookie.

Currently (9 months later) I don't remember why I needed to change the process_frame function.
It may have been a hack or it may have been a legitimate change.
Is it possible from a wsock perspective that even the begining_message to be so fragmented that this change have a sense ?

Copy link
Owner

@madtrick madtrick Mar 22, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible from a wsock perspective that even the begining_message to be so fragmented that this change have a sense ?

@ctradu I don't think so.

When you call decode/2 with new data this data will be tagged with the atom begin_message. Further in the processing chain we call process_frames/3 with the frames extracted from that data. Then we analize frame by frame and we decide if we that frame belongs to a full message or a fragmented one. This means that some data that was initially tagged as begin_message can be now tagged as continue_message (this is the case for fragmented messages). This means that sucessive calls to process_frame/2 for frames belonging to fragmented messages will always have the type continue_message.

And when we call process_frame/2 with the first frame of data tagged as begin_message the contextualize_frame/1 function can't return continue for frames which are the first in a message since according to the rfc the fragmented messages must start with an opcode other than 0 which means that process_frame/4 will match for open_continue and not for continue.

I don't know if this clarifies your doubts. If not please ask again

frame_for_fragmented_message(Frame, Message);
process_frame(continue, continue_message, Frame, Message) ->
frame_for_fragmented_message(Frame, Message);
process_frame(continue_close, continue_message, Frame, Message) ->
Expand Down