[asterisk-app-dev] Removal of api_key

[Paul Belanger]

On Thu, Oct 17, 2013 at 1:49 PM, Corey Edwards <tensai at zmonkey.org> wrote:
> On Thu, Oct 17, 2013 at 11:21 AM, Paul Belanger
> <paul.belanger at polybeacon.com> wrote:
>> On Thu, Oct 17, 2013 at 11:54 AM, Corey Edwards <tensai at zmonkey.org> wrote:
>>> On Thu, Oct 17, 2013 at 8: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 Perl Protocol::WebSocket library does not support Basic auth and having
>>> api_key available was a very useful feature to me. I could imagine many other
>>> websocket libraries being the same way. Compared to basic auth, I don't
>>> see any significant security risk.
>>>
>> So, I just wrote a basic demo in perl, man what a pain getting cpan
>> working on my linux box.  You look to be correct about
>> Protocol::WebSocket, however I was able to get basic auth working[1]
>> using Mojo::UserAgent.
>>
>> Again, I feel we're adding api_key to work around to clients would
>> don't properly support WS.
>
> I don't disagree with you, it would be nice if they all supported WS completely,
> but I don't find api_key so negative. It seems very similar to the
> ARIN REST API[1],
> just to name one. If it's an easy feature to maintain in res_ari, I
> don't see a reason
> to remove it.
>
> Corey
>
> 1. https://www.arin.net/resources/restfulmethods.html
>
Yes, but we are not using the apikey in that fashion[1], we are just
using it to transmit plain text username / password. For me, I think
that is the biggest issue.  Yes, basic auth does that too, but do we
really need to create our own implementation of it to handle clients
that don't support basic auth?  Lets remove, and working on adding
OAuth 2.0 is we really want to use a token / apikey system or even
digest auth.

And yes, I know the only really way to deal with plaintext over http
is to use SSL/TLS.  I'm actually working on testing that out this
afternoon.

[1] http://restcookbook.com/Basics/loggingin/

-- 
Paul Belanger | PolyBeacon, Inc.
Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode)
Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger