[asterisk-app-dev] Removal of api_key

[Daniel Jenkins]

On Thu, Oct 17, 2013 at 7:03 PM, Paul Belanger <paul.belanger at polybeacon.com
> wrote:

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


>From what I've read, Chrome doesn't even support basic auth over WS...

In my view (and that of pretty much any web developer) - passwords should
NEVER be in plain text when it comes to these situations, in a basic auth
header, the values are encoded in base64, granted that doesn't really
protect you at all as it can just be decoded...

So I would be looking for some kind of tokenisation, whether that comes
from oauth I'm not sure; due to the nature of the api.

Definitely a tough discussion - there doesn't seem to be a right solution,
you can see why David went down the route he did to get something out the
door! I don't think we appreciate the difficulties some of the time!

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-app-dev/attachments/20131017/887713a5/attachment.html>