+1! I'd love to move to something other than basic auth but know this may not be possible right now. Feels like something like this falls under the realms of tokens as uuids rather than oauth etc - generate a uuid, store than in ari.conf, different permissions on that token, such as number of requests allowed etc etc But yes, agree with everything that Paul says here, the swagger UI is purely HTML/CSS and JS isn't it? If so, you could just host it on an s3 bucket or something similar, no hosting/webservers required as such. But then you get into cost etc. Dan On Thu, Oct 17, 2013 at 6:22 AM, Paul Belanger <paul.belanger at polybeacon.com > wrote: > Okay, okay, hear me out before you judge, I hope to make a validate > argument, > > So, for those at home who already seen my topic on #asterisk-dev[1], > my comments are the same. I believe having api_key is a redundant > method to authenticate with ARI. > > 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). > > So, since api_key is basically bypassing the Basic Authorization > header, I think it has to go. Simply because, swagger[2] actually > does support basic auth. Now, here is where my logic takes a turn (for > the good). > > Currently, 99.9998% of all documentation about using ARI and swagger > link to the following site[3], something that we don't have control > over. So, I am proposing 2 things: > > A) remove api_key from asterisk (see above for reason). > B) Create https://swagger.asterisk.org with basic-auth header support > enabled. > > 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. > > 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. > > If work load is an issue for Digium to create swagger.asterisk.org, I > am willing to step up and do the work. I don't think it would be too > hard to get rackspace or some other cloud provider to provider a VM > for an open source project. I'll be more then happy to provision, > configure and pass the credentials to somebody else to maintain, and > if not, I'd maintain it too. > > Please consider this, having 2 different way to authenticate because a > client doesn't implement the other is redundant and not cool. > > [1] http://ibot.rikers.org/%23asterisk-dev/20130812.html.gz > [2] > https://github.com/wordnik/swagger-ui#custom-header-parameters---for-basic-auth-etc > [3] http://petstore.swagger.wordnik.com/ > > -- > Paul Belanger | PolyBeacon, Inc. > Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode) > Github: https://github.com/pabelanger | Twitter: > https://twitter.com/pabelanger > > _______________________________________________ > asterisk-app-dev mailing list > asterisk-app-dev at lists.digium.com > http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131017/8122a971/attachment-0001.html>
