On Thu, Oct 17, 2013 at 10: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 issue I see with that, is no other API service I think of would allow a user to expose there username / password like this. Sure, basic auth is just as basic, but that's the whole reason for using the HTTP headers for it. And adding this work around because a client doesn't handle basic auth properly, seems like the wrong approach. Lets fix the clients and not reimplement something in asterisk. >> In fact, I strongly think we should be hosting our own content, simply >> because we can control it and it is the friendly thing to do. Pushing >> all our users to [3] doesn't appear to be too friendly, plus just >> imagine all the asterisk themeing that could be done to it. > > Agreed. http://ari.asterisk.org is now live (also > https://ari.asterisk.org, if you enable TLS in http.conf) > > The code posted there is from my fork on GitHub[1] > Perfect! So, now that this is up and running we can do some customizations, assume I can get people on board with api_key removal (looks at dan). >> Don't get me wrong, I would be infavor of implementing some sort of >> OAuth key over the ARI, but I don' think that is in the cards at this >> point in time. And again, I think api_key is just implemented to work >> around the fact that [3] does pass basic-auth. > > I don't see why adding OAuth would be any less redundant than > ?api_key. > Well, we don't offer any sort of challenge token with api_key today, it is a simple alias to support clients that don't implement basic auth. So, if we did implement OAuth (2.0) it would be different in that aspect. Add to the fact the username : password are embedded in your URL's with api_key, any sort of debugging or sharing of log files would be a pain to sanitize. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
