<div dir="ltr"><div class="gmail_extra">On Thu, Oct 17, 2013 at 7:03 PM, Paul Belanger <span dir="ltr"><<a href="mailto:paul.belanger@polybeacon.com" target="_blank">paul.belanger@polybeacon.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Oct 17, 2013 at 1:49 PM, Corey Edwards <<a href="mailto:tensai@zmonkey.org">tensai@zmonkey.org</a>> wrote:<br>

> On Thu, Oct 17, 2013 at 11:21 AM, Paul Belanger<br>
> <<a href="mailto:paul.belanger@polybeacon.com">paul.belanger@polybeacon.com</a>> wrote:<br>
>> On Thu, Oct 17, 2013 at 11:54 AM, Corey Edwards <<a href="mailto:tensai@zmonkey.org">tensai@zmonkey.org</a>> wrote:<br>
>>> On Thu, Oct 17, 2013 at 8:05 AM, David M. Lee <<a href="mailto:dlee@digium.com">dlee@digium.com</a>> wrote:<br>
>>>><br>
>>>> On Oct 17, 2013, at 12:22 AM, Paul Belanger <<a href="mailto:paul.belanger@polybeacon.com">paul.belanger@polybeacon.com</a>> wrote:<br>
>>>><br>
>>>>> Now, the reason for having it was because this was the default way<br>
>>>>> swagger passed credentials via HTTP.  I'm not sure why they didn't<br>
>>>>> simply add <a href="http://username:password@example.org" target="_blank">http://username:password@example.org</a> support, but that is a<br>
>>>>> different issue (in fact I plan to open a bug upstream).<br>
>>>><br>
>>>> There have been a few cases where an HTTP or WebSocket client library<br>
>>>> didn't support HTTP Basic auth. Putting the HTTP Basic auth header in<br>
>>>> there is not hard, but adding an ?api_key param is dead simple.<br>
>>><br>
>>> The Perl Protocol::WebSocket library does not support Basic auth and having<br>
>>> api_key available was a very useful feature to me. I could imagine many other<br>
>>> websocket libraries being the same way. Compared to basic auth, I don't<br>
>>> see any significant security risk.<br>
>>><br>
>> So, I just wrote a basic demo in perl, man what a pain getting cpan<br>
>> working on my linux box.  You look to be correct about<br>
>> Protocol::WebSocket, however I was able to get basic auth working[1]<br>
>> using Mojo::UserAgent.<br>
>><br>
>> Again, I feel we're adding api_key to work around to clients would<br>
>> don't properly support WS.<br>
><br>
> I don't disagree with you, it would be nice if they all supported WS completely,<br>
> but I don't find api_key so negative. It seems very similar to the<br>
> ARIN REST API[1],<br>
> just to name one. If it's an easy feature to maintain in res_ari, I<br>
> don't see a reason<br>
> to remove it.<br>
><br>
> Corey<br>
><br>
> 1. <a href="https://www.arin.net/resources/restfulmethods.html" target="_blank">https://www.arin.net/resources/restfulmethods.html</a><br>
><br>
</div></div>Yes, but we are not using the apikey in that fashion[1], we are just<br>
using it to transmit plain text username / password. For me, I think<br>
that is the biggest issue.  Yes, basic auth does that too, but do we<br>
really need to create our own implementation of it to handle clients<br>
that don't support basic auth?  Lets remove, and working on adding<br>
OAuth 2.0 is we really want to use a token / apikey system or even<br>
digest auth.<br>
<br>
And yes, I know the only really way to deal with plaintext over http<br>
is to use SSL/TLS.  I'm actually working on testing that out this<br>
afternoon.<br>
<br>
[1] <a href="http://restcookbook.com/Basics/loggingin/" target="_blank">http://restcookbook.com/Basics/loggingin/</a><br>
<div class="im HOEnZb"><br>
--<br>
Paul Belanger | PolyBeacon, Inc.<br>
Jabber: <a href="mailto:paul.belanger@polybeacon.com">paul.belanger@polybeacon.com</a> | IRC: pabelanger (Freenode)<br>
Github: <a href="https://github.com/pabelanger" target="_blank">https://github.com/pabelanger</a> | Twitter: <a href="https://twitter.com/pabelanger" target="_blank">https://twitter.com/pabelanger</a></div></blockquote><div>
<br></div><div><br></div><div>From what I've read, Chrome doesn't even support basic auth over WS...</div><div><br></div><div>In my view (and that of pretty much any web developer) - passwords should NEVER be in plain text when it comes to these situations, in a basic auth header, the values are encoded in base64, granted that doesn't really protect you at all as it can just be decoded...</div>
<div><br></div><div>So I would be looking for some kind of tokenisation, whether that comes from oauth I'm not sure; due to the nature of the api.</div><div><br></div><div>Definitely a tough discussion - there doesn't seem to be a right solution, you can see why David went down the route he did to get something out the door! I don't think we appreciate the difficulties some of the time!</div>
<div><br></div><div>Dan</div><div><br></div></div><br></div></div>