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
