[asterisk-app-dev] Removal of api_key

[Paul Belanger]

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@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