[asterisk-app-dev] Removal of api_key

[David M. Lee]

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

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

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

-- 
David M. Lee
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org