[asterisk-dev] Asterisk 12 API improvements

[Dan Jenkins]

Going back to Authentication and Authorisation,

I talked about tokens but now I think about it a bit more, it seems as
though each module off of stasis should take care of it's own form of
authentication, tokens or extra headers make sense for an HTTP request but
doesn't make sense for something else,

So statis-core should deal with "an authed client" and
"their privileges are x,y and z" but it shouldn't have anything to do with
how a client is authenticated, stasis-http would deal with basic-auth,
extra headers, tokens etc, and just pass an auth'd client to stasis itself.

What do others think about this?

Dan

-- 
Dan Jenkins - Senior Web Developer
email: dan.jenkins at holidayextras.com
twitter: dan_jenkins <http://twitter.com/dan_jenkins>
linkedin: jenkinsdaniel <http://www.linkedin.com/in/jenkinsdaniel>
skype: d-jenkins
blog: www.dan-jenkins.co.uk
about.me: about.me/dan_jenkins



On 1 December 2012 11:40, Dan Jenkins <dan.jenkins at holidayextras.com> wrote:

> Hi All,
>
> Thought I'd put some comments against parts of the wiki,
>
> *We're going to start with fixing one of the most glaring problems with
> the current APIs: add a stable identifier to channels<https://issues.asterisk.org/jira/browse/ASTERISK-20725>,
> and use that identifier consistently throughout AMI. This solves a big
> problem for current AMI+AGI based applications. - **LOVE this!*
>
> *Unfortunately, solving some of the larger problems would be very
> intrusive with the current API's, and introduce a host of breaking changes.
> Some are so fundamental, we would essentially be rewriting the interface.
> That's not acceptable; the current API's aren't going anywhere anytime
> soon. *- *Is there not scope to enhance these APIs? There was discussion
> a few weeks back on this mailing list about enhancing the AMI to support
> JSON/XML rather than key value return separated strings (After reading
> further down there is a line saying "**AMI Event Structure - AMI events
> should be generated into a key/value object pair instead of the printf-style
> string formatting currently used. This would allow Stasis to reuse the
> existing events.**" - Does this mean that the suggestion above needs to
> happen anyway?)*
> *
> *
>  *The **stasis-http** component will be built upon this message bus to
> expose a RESTful API, also utilizing WebSockets for asynchronous
> communication to the external applications.* - *Can you go into a bit
> more detail about why this API would use Websockets? What kinds of
> scenarios do you see someone interacting with Asterisk directly with
> Websockets, in an API type of way? I wouldn't allow a browser to connect
> directly to Asterisk for example, I would get it going through a middle
> server that connects to Asterisk and it's sole purpose is to connect to
> hundreds of clients using websockets. I think we have to be careful about
> wanting to make this new API accessible for everyone but still keep
> Asterisk doing what it's good at, I hope this makes sense... However, I can
> also see how connecting with websockets from a server could be useful, but
> I think I'd rather keep a RESTful interface, where you can tell Asterisk
> "for an event that you would emit about x you need to send the data to uri
> y as an HTTP call" and let the data be consumed that way.*
>
> Even so, I love the fact that Stasis is happening - it's the best way to
> get web developers using such a "toolkit" as it's put - if it's done right
> it could open the doors to some amazing applications.
>
> In terms of Authentication and Authorisation, I'd like to see more of an
> effort behind this, with mechanisms to create tokens to be used rather than
> user and pass in plain text or even the handshake system currently in
> Asterisk, this is something that isn't a huge issue right now with
> Asterisk's current APIs but if we're looking at HTTP first with stasis then
> we should be thinking about how this would be best used within HTTP and
> make sure it works for other implementations too.
>
> In terms of encryption, shouldn't this be down to the libraries off of
> stasis? So stasis-http would take care of encryption within it, as
> different protocols have different forms of encryption which is relevant
> those those protocols? Is this the plan?
>
> I also agree with Olle on the granularity of permissions of users within
> this API, but for a different reason, the AMI has basic granularity in
> terms of what it's able to do, which is used enormously, why wouldn't you
> do something similar within this new API system?
>
> I'm sure we'll have to add to that high level list of summary features, as
> I'm sure we'll end up thinking of more solutions that would be perfect for
> this type of interface, I'm interested to see what other tasks other people
> think could be achieved using such an API
>
> Let me know if I've misinterpreted anything in the wiki,
>
> Dan
>
> --
> Dan Jenkins - Senior Web Developer
> email: dan.jenkins at holidayextras.com
> twitter: dan_jenkins <http://twitter.com/dan_jenkins>
> linkedin: jenkinsdaniel <http://www.linkedin.com/in/jenkinsdaniel>
> skype: d-jenkins
> blog: www.dan-jenkins.co.uk
> about.me: about.me/dan_jenkins
>
>
>
> On 27 November 2012 05:16, David M. Lee <dlee at digium.com> wrote:
>
>> Greetings all!
>>
>> I hope that everyone stateside enjoyed their Thanksgiving holiday. For
>> everyone else, I hope you somehow managed to enjoy yourselves without
>> massive amounts of turkey and various side dishes.
>>
>> Now that I'm back to work, I'd like to kick off an endeavor that I
>> know several folks on the -dev list are interested in: improving the
>> API's for Asterisk 12.
>>
>> I've just created a project page for the effort:
>> https://wiki.asterisk.org/wiki/x/CoZHAQ
>>
>> I started writing a short summary of what we see happening for this
>> effort, but that turned into a giant wall of text. Rather than burden
>> your email with a crazy long email, I added some background and
>> rationale to the 'Project Overview' section of the project page.
>>
>> I have some further ideas about the overall design, and specifics of
>> the API itself. But rather than get too far ahead of ourselves, let's
>> get some feedback on the requirements and overview of what we want to
>> do.
>>
>> Thoughts?
>> --
>> 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
>>
>>
>> --
>> _____________________________________________________________________
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20121201/452d8653/attachment.htm>