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
