On Thu, Oct 17, 2013 at 7:03 PM, Paul Belanger <paul.belanger at polybeacon.com > wrote: > On Thu, Oct 17, 2013 at 1:49 PM, Corey Edwards <tensai at zmonkey.org> wrote: > > On Thu, Oct 17, 2013 at 11:21 AM, Paul Belanger > > <paul.belanger at polybeacon.com> wrote: > >> On Thu, Oct 17, 2013 at 11:54 AM, Corey Edwards <tensai at zmonkey.org> > wrote: > >>> On Thu, Oct 17, 2013 at 8:05 AM, David M. Lee <dlee at digium.com> wrote: > >>>> > >>>> On Oct 17, 2013, at 12:22 AM, Paul Belanger < > paul.belanger at polybeacon.com> wrote: > >>>> > >>>>> Now, the reason for having it was because this was the default way > >>>>> swagger passed credentials via HTTP. I'm not sure why they didn't > >>>>> simply add http://username:password at example.org support, but that > is a > >>>>> different issue (in fact I plan to open a bug upstream). > >>>> > >>>> There have been a few cases where an HTTP or WebSocket client library > >>>> didn't support HTTP Basic auth. Putting the HTTP Basic auth header in > >>>> there is not hard, but adding an ?api_key param is dead simple. > >>> > >>> The Perl Protocol::WebSocket library does not support Basic auth and > having > >>> api_key available was a very useful feature to me. I could imagine > many other > >>> websocket libraries being the same way. Compared to basic auth, I don't > >>> see any significant security risk. > >>> > >> So, I just wrote a basic demo in perl, man what a pain getting cpan > >> working on my linux box. You look to be correct about > >> Protocol::WebSocket, however I was able to get basic auth working[1] > >> using Mojo::UserAgent. > >> > >> Again, I feel we're adding api_key to work around to clients would > >> don't properly support WS. > > > > I don't disagree with you, it would be nice if they all supported WS > completely, > > but I don't find api_key so negative. It seems very similar to the > > ARIN REST API[1], > > just to name one. If it's an easy feature to maintain in res_ari, I > > don't see a reason > > to remove it. > > > > Corey > > > > 1. https://www.arin.net/resources/restfulmethods.html > > > Yes, but we are not using the apikey in that fashion[1], we are just > using it to transmit plain text username / password. For me, I think > that is the biggest issue. Yes, basic auth does that too, but do we > really need to create our own implementation of it to handle clients > that don't support basic auth? Lets remove, and working on adding > OAuth 2.0 is we really want to use a token / apikey system or even > digest auth. > > And yes, I know the only really way to deal with plaintext over http > is to use SSL/TLS. I'm actually working on testing that out this > afternoon. > > [1] http://restcookbook.com/Basics/loggingin/ > > -- > Paul Belanger | PolyBeacon, Inc. > Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode) > Github: https://github.com/pabelanger | Twitter: > https://twitter.com/pabelanger > >From what I've read, Chrome doesn't even support basic auth over WS... 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... 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. 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! Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131017/887713a5/attachment.html>
