On Thu, Oct 17, 2013 at 10:58 AM, David M. Lee <dlee at digium.com> wrote: > > On Oct 17, 2013, at 9:25 AM, Paul Belanger <paul.belanger at polybeacon.com> wrote: > >> 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. > > But there are plenty the expose an API key, which is effectively a > username and password wrapped up in a single token. The exposure is > the same; if someone obtains your API key, the exposure is no > different than if they obtained a username+password. > Can you be more specific who does it? Because I cannot find anybody that will pass ?key=username:password for a URL request like we do. I know I am beating this like a horse, but I don't believe how we do api_key actually adds any functionality, and specifically a supported way via an RFC[1]. >>> 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). > > I have no interest in maintaing a significant fork of swagger-ui > forever. Even the very minor mods I put in to change the default URL > are annoying to maintain. > > If you can get changes accepted upstream, then great. > Again, I offered up my services to maintain the swagger configuration if you don't want too., >>>> 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. > > So far, this is the only thing you've mentioned that is an actual > problem with ?api_key, as compared to Basic auth. But if that is the > case, then simply don't use it. It is available for the situations > where it is useful, but Basic auth is there for when it's a problem. > Sorry if I have not maybe myself clear, but my issue with api_key it is only implemented to work around clients that don't support additional header fields[2]. I feel pain for that, but like I have mentioned, we should not be duplicating functionality because clients don't support http basic auth. We should be working with upstream clients to properly support them. [1] https://tools.ietf.org/rfc/rfc2617.txt [2] http://tools.ietf.org/html/rfc6455#page-19 -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
