Summary:	ASTERISK-02466: Asterisk Manager Proxy -- simpleproxy.pl
Reporter:	davetroy (davetroy)	Labels:
Date Opened:	2004-09-25 15:59:27	Date Closed:	2008-01-15 15:12:26.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) managerproxy.pl ( 1) simpleproxy.pl ( 2) simpleproxy-1_01.pl
Description:	If you have developed CGI, PHP or other synchronous web-based applications that utilize the Asterisk manager interface, you know that they don't scale well, since each invocation from the web requires a connection to Asterisk and authentication there (thus putting a potentially large amount of connection and authentication load directly onto asterisk). There has been some discussion as to how to address this; some folks are talking about databases, others have developed specialized 'middleware' to bridge between the code at the edge and Asterisk. Nicolas Gudino's Flash Operator Panel is one such piece of code. I had a need for a much simpler proxy than his op_server.pl; to meet my need I re-worked and simplified his code.   It's *very* simple: connects to Asterisk manager with a single authenticated connection, and listens on a configurable port (1234 by default) for inbound connections. Any commands passed from client->proxy are forwarded to Asterisk.  Any events passed from asterisk->proxy are forwarded to all connected clients. They all share a common connection context so all clients will see the same thing, all clients will share the rights of the authenticated user. I make no pretense that this is particularly good code;  I'm putting it out there for now as it helps me with testing something I'm working on, and it may be of use to others -- maybe we can start the ball rolling on something a bit more robust. Uses for this include: - Making a web-services/XMLRPC wrapper for asterisk manager - Building simple web-based applications - Backend for scalable, heterogeneous operator panels - Insulating Asterisk manager internals from user community Some potential next steps/enhancements for this basic design might be: - Test for robustness/IO interruptions on either side - Creating a connection pool of n (configurable) connections to * manager - Tracking connection contexts for clients - Redo with c/pthreads for speed (imapproxy is someplace to look) - Utilize libwrap to control access - Implement a simple authentication mechanism - Add TLS to clients for secure manager interactions - Drop privs to run as alternate user/group Right now it is assumed that you will use this proxy in a secured environment -- either listening on localhost only, on a private LAN or behind a firewall.  If you do not take some precautions you may be opening up a completely unauthenticated proxy to your * box!! ****** ADDITIONAL INFORMATION ****** This should be OK to include in asterisk/contrib.  I have a disclaimer on file, but this code isn't GPL'd (see license which was taken from Nicolas Gudino's -- just passing on his license from his [heavily] modified code).
Comments:	By: Mark Spencer (markster) 2004-09-25 17:35:38 Certainly I have no problem with BSD licensed code, but can we preferably drop the advertising clause or at the very least have it modified to look more like the editline code's advertising clause (which basically says it's only relevent for materials talking about this feature/software)?  Thanks. By: rwjblue (rwjblue) 2004-09-26 00:08:11 Initial testing proves promising.  I am looking into adding XMLRPC handler.  Would you like to integrate it in or keep it separate? By: davetroy (davetroy) 2004-09-26 09:54:21 Mark -- I've pinged Nicolas Gudino to see if he's OK with GPL'ing this code; would make things simpler. rwjblue -- Thinking about it some, I think it might be sensible to keep things separate.  There are established modules for XMLRPC and SOAP for Apache and other environments, plus decent access control mechanisms, plus decent protection from network-side abuse.  If we try to do all that in the proxy we'll end up re-writing Apache. If you do the HTTP/XML work in Apache/IIS/whatever, and then this proxy server is accessed only by trusted web server hosts, that's a scalable, reasonably secure environment.  In addition, it gives the freedom to focus development exclusively on the proxy function and not handling different external API's. If I decide to rewrite this proxy in c/pthreads, you can just drop in the 'new improved' proxy and not have to change anything. You're still able to code directly to the Manager API; all changes to * are passed through directly (no modifying proxy when * adds a feature); all external apps can code to the Manager API.  If anybody wants to build a custom language/state machine/etc to talk to a new kind of client, they can test direct to manager first, then switch to talking to simpleproxy instead when they need to scale. So my recommendation would be to write an XMLRPC handler for Apache that connects to Manager and test that.  Then have it talk to simpleproxy.  I have implemented SOAP with Apache successfully.  Something involving Apache/mod_perl as an XMLRPC/SOAP server talking to simpleproxy.pl would be very efficient. Also, if I didn't say so, if you run 'simpleproxy.pl -d' it will fork and run as a background daemon; without -d it runs in the foreground with debug info on stdout. By: nicolasg (nicolasg) 2004-09-26 10:02:50 I have no problem changing the license to GLP or whatever you need to get the project going. Just let me know what do I have to do... By: davetroy (davetroy) 2004-09-26 10:25:16 OK, per Nicolas' permission to change to GPL, that has been done, and a couple of tiny mods made; released as version 1.01 and ready to go! By: Olle Johansson (oej) 2004-10-10 10:40:37 One thing is GPL, another is if you have disclaimed the code to Digium, both of you? We need the copyright holders to disclaim the code (see bug tracker introduction) in order to include it in CVS. Otherwise, we need to include it in addons or another distribution method. By: davetroy (davetroy) 2004-10-11 20:34:09 I have a disclaimer on file with Digium, not sure about Nicolas.  Nicolas, do you? By: nicolasg (nicolasg) 2004-10-11 21:10:05 Yes, I do. By: Brian West (bkw918) 2004-10-17 18:55:26 So its ok to put this in?  You disclaim it? both of you? By: nicolasg (nicolasg) 2004-10-18 13:08:33 Yes, its ok for me to include it where you see fit. I have the disclaimer on file since january. I can send a fax again if necessary. By: Mark Spencer (markster) 2004-10-25 23:59:35 Added to CVS, thank you both very much! By: Russell Bryant (russell) 2004-10-26 10:34:06 not included in 1.0 By: Olle Johansson (oej) 2004-11-02 13:26:28.000-0600 The file in CVS is broken. HTML encoded and with wrong carriage returns... Here's a working copy. Also, I've added some instructions to the config section. By: Mark Spencer (markster) 2004-11-02 17:32:26.000-0600 Fixed in CVS By: Digium Subversion (svnbot) 2008-01-15 15:11:47.000-0600 Repository: asterisk Revision: 4102 A   trunk/contrib/scripts/managerproxy.pl ------------------------------------------------------------------------ r4102 | markster | 2008-01-15 15:11:47 -0600 (Tue, 15 Jan 2008) | 2 lines Add manager proxy (bug ASTERISK-2466) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=4102 By: Digium Subversion (svnbot) 2008-01-15 15:12:26.000-0600 Repository: asterisk Revision: 4149 U   trunk/contrib/scripts/managerproxy.pl ------------------------------------------------------------------------ r4149 | markster | 2008-01-15 15:12:26 -0600 (Tue, 15 Jan 2008) | 2 lines Fix managerproxy (bug ASTERISK-2466) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=4149