Going back to Authentication and Authorisation,<div><br></div><div>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, </div>
<div><br></div><div>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.</div>
<div><br></div><div>What do others think about this?</div><div><br></div><div>Dan</div><div class="gmail_extra"><br clear="all"><font face="arial, helvetica, sans-serif" color="#333333">-- <br>Dan Jenkins - Senior Web Developer<br>
email: <a href="mailto:dan.jenkins@holidayextras.com" target="_blank">dan.jenkins@holidayextras.com</a><br>twitter: <a href="http://twitter.com/dan_jenkins" target="_blank">dan_jenkins</a><br>linkedin: <a href="http://www.linkedin.com/in/jenkinsdaniel" target="_blank">jenkinsdaniel</a><br>
skype: <a>d-jenkins</a></font><div><font face="arial, helvetica, sans-serif" color="#333333">blog: <a href="http://www.dan-jenkins.co.uk/" target="_blank">www.dan-jenkins.co.uk</a></font></div><div><font face="arial, helvetica, sans-serif" color="#333333"><a href="http://about.me" target="_blank">about.me</a>: <a href="http://about.me/dan_jenkins" target="_blank">about.me/dan_jenkins</a></font></div>
<br>
<br><br><div class="gmail_quote">On 1 December 2012 11:40, Dan Jenkins <span dir="ltr"><<a href="mailto:dan.jenkins@holidayextras.com" target="_blank">dan.jenkins@holidayextras.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi All, <div><br></div><div>Thought I'd put some comments against parts of the wiki,</div><div><br></div><div><i><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px">We're going to start with fixing one of the most glaring problems with the current APIs: </span><a href="https://issues.asterisk.org/jira/browse/ASTERISK-20725" rel="nofollow" style="color:rgb(0,109,175);text-decoration:initial;outline:none;font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px" target="_blank">add a stable identifier to channels</a><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px">, and use that identifier consistently throughout AMI. This solves a big problem for current AMI+AGI based applications.</span><b> - </b></i><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px"><b>LOVE this!</b></span></div>
<div><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px"><br></span></div><div><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px"><i>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. </i>- <b>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 "</b></span><i><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px">AMI Event Structure</span><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px"> - AMI events should be generated into a key/value object pair instead of the </span><tt style="color:rgb(51,51,51);font-size:13px;line-height:17.33333396911621px">printf</tt><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px">-style string formatting currently used. This would allow Stasis to reuse the existing events.</span></i><b style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px">" - Does this mean that the suggestion above needs to happen anyway?)</b></div>
<div><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px"><b><br></b></span></div><div><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px"> <i>The </i></span><tt style="color:rgb(51,51,51);font-size:13px;line-height:17.33333396911621px"><i>stasis-http</i></tt><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px"><i> component will be built upon this message bus to expose a RESTful API, also utilizing WebSockets for asynchronous communication to the external applications.</i> - <b>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.</b></span><br>
</div><div><br></div><div><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px">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.</span></div>
<div><span style="color:rgb(51,51,51);font-family:Arial,Helvetica,FreeSans,sans-serif;font-size:13px;line-height:17.33333396911621px"><br></span></div><div><font color="#333333" face="Arial, Helvetica, FreeSans, sans-serif"><span style="line-height:17.33333396911621px">In terms of Authentication and </span></font><font color="#333333" face="Arial, Helvetica, FreeSans, sans-serif"><span style="line-height:17.33333396911621px">Authorisation</span></font><font color="#333333" face="Arial, Helvetica, FreeSans, sans-serif"><span style="line-height:17.33333396911621px">, 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.</span></font></div>
<div><font color="#333333" face="Arial, Helvetica, FreeSans, sans-serif"><span style="line-height:17.33333396911621px"><br></span></font></div><div><font color="#333333" face="Arial, Helvetica, FreeSans, sans-serif"><span style="line-height:17.33333396911621px">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?</span></font></div>
<div><font color="#333333" face="Arial, Helvetica, FreeSans, sans-serif"><span style="line-height:17.33333396911621px"><br></span></font></div><div><font color="#333333" face="Arial, Helvetica, FreeSans, sans-serif"><span style="line-height:17.33333396911621px">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?</span></font></div>
<div><br></div><div><font color="#333333" face="Arial, Helvetica, FreeSans, sans-serif"><span style="line-height:17.33333396911621px">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</span></font></div>
<div><font color="#333333" face="Arial, Helvetica, FreeSans, sans-serif"><span style="line-height:17.33333396911621px"><br></span></font></div><div><font color="#333333" face="Arial, Helvetica, FreeSans, sans-serif"><span style="line-height:17.33333396911621px">Let me know if I've misinterpreted anything in the wiki,</span></font></div>
<div><font color="#333333" face="Arial, Helvetica, FreeSans, sans-serif"><span style="line-height:17.33333396911621px"><br></span></font></div><div><font color="#333333" face="Arial, Helvetica, FreeSans, sans-serif"><span style="line-height:17.33333396911621px">Dan</span></font></div>
<span class="HOEnZb"><font color="#888888">
</font></span><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><font face="arial, helvetica, sans-serif" color="#333333">-- <br>Dan Jenkins - Senior Web Developer<br>email: <a href="mailto:dan.jenkins@holidayextras.com" target="_blank">dan.jenkins@holidayextras.com</a><br>
twitter: <a href="http://twitter.com/dan_jenkins" target="_blank">dan_jenkins</a><br>linkedin: <a href="http://www.linkedin.com/in/jenkinsdaniel" target="_blank">jenkinsdaniel</a><br>skype: <a>d-jenkins</a></font><div><font face="arial, helvetica, sans-serif" color="#333333">blog: <a href="http://www.dan-jenkins.co.uk/" target="_blank">www.dan-jenkins.co.uk</a></font></div>
<div><font face="arial, helvetica, sans-serif" color="#333333"><a href="http://about.me" target="_blank">about.me</a>: <a href="http://about.me/dan_jenkins" target="_blank">about.me/dan_jenkins</a></font></div></font></span><div>
<div class="h5"><br>
<br><br><div class="gmail_quote">On 27 November 2012 05:16, David M. Lee <span dir="ltr"><<a href="mailto:dlee@digium.com" target="_blank">dlee@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Greetings all!<br>
<br>
I hope that everyone stateside enjoyed their Thanksgiving holiday. For<br>
everyone else, I hope you somehow managed to enjoy yourselves without<br>
massive amounts of turkey and various side dishes.<br>
<br>
Now that I'm back to work, I'd like to kick off an endeavor that I<br>
know several folks on the -dev list are interested in: improving the<br>
API's for Asterisk 12.<br>
<br>
I've just created a project page for the effort:<br>
<a href="https://wiki.asterisk.org/wiki/x/CoZHAQ" target="_blank">https://wiki.asterisk.org/wiki/x/CoZHAQ</a><br>
<br>
I started writing a short summary of what we see happening for this<br>
effort, but that turned into a giant wall of text. Rather than burden<br>
your email with a crazy long email, I added some background and<br>
rationale to the 'Project Overview' section of the project page.<br>
<br>
I have some further ideas about the overall design, and specifics of<br>
the API itself. But rather than get too far ahead of ourselves, let's<br>
get some feedback on the requirements and overview of what we want to<br>
do.<br>
<br>
Thoughts?<br>
--<br>
David M. Lee<br>
Digium, Inc. | Software Developer<br>
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA<br>
Check us out at: <a href="http://www.digium.com" target="_blank">www.digium.com</a> & <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a><br>
<br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</blockquote></div><br></div></div></div>
</blockquote></div><br></div>