[asterisk-app-dev] Removal of api_key

[Paul Belanger]

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