HTTP Basic Auth + at least yaws

[stuart-thackray]

Hi,

I have not had this problem in previous versions of simple bridge and yaws.

At least with a fresh pull of nitrogen & when you are trying to using HTTP Basic Auth it crashes. (Below is the crash).

For reference I was able to obtain the parameters i.e. username and password using the following code previously.

Headers = wf:headers(),
{value, {_, {UserName, Password, _}}} = lists:keysearch(authorization, 1, Headers),

I am not sure if this should be handled via sbw, yaws bridge modules or simple_bridge_util (i.e. I thought of adding "to_binary(T) when is_tuple(T) ->
T;" but this is probably not right. I will try another webserver and attempt to see if I get the same result.

=ERROR REPORT==== 25-Mar-2015::15:08:03 ===
Error in simple_bridge:make/2 - error - badarg
[{erlang,iolist_to_binary,
[{"stuart_airtime","psswd","Basic c3R1YXJ0X2FpcnRpbWU6cHNzd2Q="}],
[]},
{simple_bridge_util,to_binary,1,
[{file,"src/simple_bridge_util.erl"},{line,315}]},
{sbw,normalize_header,1,[{file,"src/sbw.erl"},{line,132}]},
{sbw,'-cache_headers/1-lc$^0/1-0-',1,[{file,"src/sbw.erl"},{line,120}]},
{sbw,'-cache_headers/1-lc$^0/1-0-',1,[{file,"src/sbw.erl"},{line,120}]},
{sbw,cache_headers,1,[{file,"src/sbw.erl"},{line,120}]},
{sbw,new,2,[{file,"src/sbw.erl"},{line,101}]},
{simple_bridge,make_nocatch,2,[{file,"src/simple_bridge.erl"},{line,94}]}]

[stuart-thackray]

I have tried with cowboy the problem seems yaws specific.

I can't think of a way to change specifically the yaws implementation.

I have tried changing the simple_bridge_util to_binary function by adding in the below but it doesn't seem to be the correct way.

to_binary(T) when is_tuple(T) ->
T;

If there is a way you would like to suggest Jesse I will make a pull request.

Kind Regards,
Stuart

[choptastic]

Hi Stuart,

Thanks for pointing this out and looking into it. I don't have an
immediate answer for you here, but I wonder if maybe the auth headers are
available in a non-preparsed way like they are with the other webservers.

I haven't worked much with the HTTP auth headers with any of the erlang
webservers, so I can't really say for sure how to fix this just yet.
Perhaps it's just a matter of making the request for those headers for yaws
when they are pre-cached to be normalized into something usable universally.

-Jesse

On Wed, Mar 25, 2015 at 10:13 AM, stuart-thackray [email protected]
wrote:

I have tried with cowboy the problem seems yaws specific.

I can't think of a way to change specifically the yaws implementation.

I have tried changing the simple_bridge_util to_binary function by adding
in the below but it doesn't seem to be the correct way.

to_binary(T) when is_tuple(T) ->
T;

If there is a way you would like to suggest Jesse I will make a pull
request.

Kind Regards,
Stuart

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

Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

[stuart-thackray]

Hi Jesse,

I have been meaning to reply to this for a while. It is not extremely urgent I think anyways.

I have gone through the yaws documentation and configuration; I have not found a way to not found a means to get the "auth headers are available in a non-preparsed way".
I am also not sure if is not a valid way that it is returned in yaws also; or at least convenient.

I like how the simple bridge was updated and upgraded, for example it seems all the HTTP headers names are now being cast to binary. I am not sure what the reasons would be I can think of it would be less heavy to pass between processes (binaries), you don't have to use atoms and the limited atom table, and it is keeps consistency on the types expected by the modules making use of it.

I have thought about many ways to attempt to make this case work.

I think the simplest is to add a different function to simple_bridge_util called something along the lines of try_to_binary/1 where if it can't cast to binary it just returns the type that wasn't cast.
Otherwise we can cast the tuple to a binary in the means of term_to_binary/1 in the to_binary/1 function (I don't particularity like this as not human readable).

If you would like to suggest if either of the above options are acceptable or make a different suggestion I will create the pull request.

[choptastic]

Hi Stuart,

I'm thinking maybe the best approach might be to add some kind of built-in
support for authentication. I'm not entirely sure what that would entail
when it comes to supporting all the backends, but if there's no way to get
the raw data from yaws.

The easier alternative might be to add an api function on the order of
sbw:get_req() to return the actual Request object for the underlying
server, so you can do whatever you want to the actual data, then maybe just
naturally avoid header normalization from yaws for that specific header.

As far as the conversion to binary and how they're stored that way, it's to
normalize the return values and do quick conversion (where each web server
does their headers and querystrings in different ways, this ensures they're
always returned the same way), and for passing around data, binary is a
more efficient format.

I'm mostly spitballing here, as I just don't know the best approach yet.
Part of what I'm trying to do with SB 2.0 is making sure you can completely
switch from one backend to another without changing any code, unlike SB
1.x, which kinda did that, but you still needed to know a little
something about the underlying server (does it use binary or lists, are
headers expected to be atoms or lists or binaries, etc).

-Jesse

On Thu, Apr 9, 2015 at 3:39 AM, stuart-thackray [email protected]
wrote:

Hi Jesse,

I have been meaning to reply to this for a while. It is not extremely
urgent I think anyways.

I have gone through the yaws documentation and configuration; I have not
found a way to not found a means to get the "auth headers are available in
a non-preparsed way".
I am also not sure if is not a valid way that it is returned in yaws also;
or at least convenient.

I like how the simple bridge was updated and upgraded, for example it
seems all the HTTP headers names are now being cast to binary. I am not
sure what the reasons would be I can think of it would be less heavy to
pass between processes (binaries), you don't have to use atoms and the
limited atom table, and it is keeps consistency on the types expected by
the modules making use of it.

I have thought about many ways to attempt to make this case work.

I think the simplest is to add a different function to simple_bridge_util
called something along the lines of try_to_binary/1 where if it can't cast
to binary it just returns the type that wasn't cast.
Otherwise we can cast the tuple to a binary in the means of
term_to_binary/1 in the to_binary/1 function (I don't particularity like
this as not human readable).

If you would like to suggest if either of the above options are acceptable
or make a different suggestion I will create the pull request.

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

Jesse Gumm
Owner, Sigma Star Systems
414.940.4866 || sigma-star.com || @jessegumm

[stuart-thackray]

Thanks Jesse thanks for response,

Very interesting response and still digesting it.

From my initial understanding is you want all webservers to be irrelevant to nitrogen or anything else.

For myself many years of using yaws I am not going to change. I would prefer that it works as yaws has it; I would prefer to change nitrogen based code than check how webserver handles it (so that why I suggested/think quicker and dirtier is better).

My general thought is I would never change webservers without a reason HTTP auth wouldn't be one. So my thought/suggestion would be what I suggested i.e. being letting it pass the to_binary/1; than spend the extra computation on times to check if header was this and then normalize it specifically. I also not understanding why people would choose nitrogen or simple bridge and need to convert to something else except for inets maybe to prod kind of server,

The repo is owned by you and I can change the code I pull for sure to make it work for myself (which I have previously done when I think it is not helpful to contribute for the community).

I will try and create a pull request if you think one is needed and how it should be handled.

Thanks.
Stuart