Summary:ASTERISK-13402: [patch] JSON Manager Event Interface
Reporter:Perssy Llamosas (pll)Labels:
Date Opened:2009-01-19 20:02:37.000-0600Date Closed:2015-03-15 02:34:54
Versions:Frequency of
Environment:Attachments:( 0) 20090520__issue14281.diff.txt
( 1) 20090528_issue0014281.diff
( 2) 20090529_issue0014281.diff
( 3) manager.c.2439891.6.2.7.diff
( 4) manager.c.261180svn.diff
( 5) manager-
( 6) manager-svn.diff
( 7) test_mjson.py
( 8) test_mjson-0.2.py
( 9) utils.diff
Description:Make it easier to work with pure javascript Asterisk managers. Just adding another option.


* Added mjson URI which outputs data in the JSON format.
Comments:By: Perssy Llamosas (pll) 2009-01-19 20:06:30.000-0600

Attached diff files to SVN-169443 and

By: Tilghman Lesher (tilghman) 2009-05-20 18:20:35

Patch updated to current trunk.

By: Leif Madsen (lmadsen) 2009-05-21 10:57:11

Assigned to dbrooks for testing!

By: David Brooks (dbrooks) 2009-05-27 16:08:51

In consulting with rbrindley, the issue came up concerning the reason for using JSON in the first place. It would seem that JSON would be used when less output is desired. Would it be ok to just return the var=val stuff, to cut down on the parsing? Or is there some other reason for doing it this way? Thanks!

By: Perssy Llamosas (pll) 2009-05-28 00:22:33

Valid json strings are between ""

A json object is made of { string : value }

This works because it's valid javascript:
{a_name:"a value"}

This is valid json:
{"a_name":"a value"}

They are both the same javascript object, but the later has a couple extra characters, seems like a waste but...

What about this case?
{a name:"a value"}

The above will fail, it's not properly formatted. The correct format is:
{"a name":"a value"}

Another problem when not using proper json strings for labels is:
{case:"a value"}

Once again, the above will fail. case is part of the javascript language so it's a restricted keyword but this works as expected:
{"case":"a value"}

With valid json labels I can even put atypical labels:
{" 12 ":"a value"}

It's desirable to have valid json labels.

By: Tilghman Lesher (tilghman) 2009-05-28 02:00:20

PLL:  I have updated your patch to apply to current trunk, although it's possible I screwed it up somehow.  Could you apply the current patch to trunk and test it?  Also, could you suggest some tests that we could do ourselves, to verify testing?

By: Perssy Llamosas (pll) 2009-05-28 23:15:08

Uploaded patch to current SVN.

There is a trivial but annoying bug, it kept chocking cookielib. Version of the cookie should be 1 not "1". Should I open a new bug?
- "Set-Cookie: mansession_id=\"%08x\"; Version=\"1\"; Max-Age=%d"
+ "Set-Cookie: mansession_id=\"%08x\"; Max-Age=%d; Version=1\r\n"

I also uploaded a parameter tester in python (requires 2.6). It connects to the manager and tests the mjson response against it.

I put the action "ListCommands" in there, I know it fails due to an extra space at the beginning of every parameter but that's something in ListCommands.

By: Tilghman Lesher (tilghman) 2009-05-29 00:16:28

PLL:  that's not a bug.  Please see RFC 2109, Section 5.  The examples there quite clearly suggest using quotes around the version number.  Since that is the official specification for the Set-Cookie header, you should assume that your client library which is choking on the quotes is not in compliance with the specification.

By: Perssy Llamosas (pll) 2009-05-29 18:06:45

You were right.

Still, that line had a "\r\n" missing.

Uploaded new diff and new tester.

By: David Brooks (dbrooks) 2009-06-02 10:40:50

PLL: Sorry, I'm not too familiar with python, unfortunately. I'm running your test script, and I get the following traceback:

Traceback (most recent call last):
 File "test_mjson-0.2.py", line 46, in <module>
   json_response = json.load(urllib2.urlopen(url))
 File "/usr/local/lib/python2.6/json/__init__.py", line 267, in load
   parse_constant=parse_constant, **kw)
 File "/usr/local/lib/python2.6/json/__init__.py", line 307, in loads
   return _default_decoder.decode(s)
 File "/usr/local/lib/python2.6/json/decoder.py", line 319, in decode
   obj, end = self.raw_decode(s, idx=_w(s, 0).end())
 File "/usr/local/lib/python2.6/json/decoder.py", line 336, in raw_decode
   obj, end = self._scanner.iterscan(s, **kw).next()
 File "/usr/local/lib/python2.6/json/scanner.py", line 55, in iterscan
   rval, next_pos = action(m, context)
 File "/usr/local/lib/python2.6/json/decoder.py", line 219, in JSONArray
   raise ValueError(errmsg("Expecting object", s, end))
ValueError: Expecting object: line 2 column 61 (char 62)

By: Perssy Llamosas (pll) 2009-06-02 14:57:01

Can you see what mjson is returning?

Apparently it says it's not a json object or is badly formatted.

By: David Brooks (dbrooks) 2009-06-02 15:37:30

I had to change the url to

Having done that, I get OKs on all tests. :)

By: Perssy Llamosas (pll) 2009-06-02 16:30:08

I am trying to use the authentication urls so I can improve the tester but I keep getting 401 unauthorized.

amanager, arawman, amxml. Do they need extra configuration?

I get a "ast_parse_digest: Missing Digest".

By: David Brooks (dbrooks) 2009-06-15 11:26:15

Sorry PLL, the code as is will always give you "Missing Digest". I have attached a patch for utils.c. Please let me know if this fixes it for you. Thanks!

By: Perssy Llamosas (pll) 2009-06-15 18:38:12

I keep getting "missing digest". Additionally after applying the patch I get a warning in compilation:

utils.c: In function ‘ast_parse_digest’:
utils.c:1946: warning: passing argument 1 of ‘strncasecmp’ from incompatible pointer type

By: David Brooks (dbrooks) 2009-06-16 13:17:34

Sorry again! Could you upload your test code so I can see what is happening?

By: Perssy Llamosas (pll) 2009-06-16 16:00:03

No test code. I am using firefox.

By: David Brooks (dbrooks) 2009-06-22 13:41:44

I've updated the patch. I think this is what the author meant. Let me know if this works. If not, let me know what you are testing it against and I will keep working on it.

By: Perssy Llamosas (pll) 2009-06-26 16:26:43

The "missing digest" problem is now gone with the patch.

But it won't authenticate either.

line 4830:
   if (!d.nonce  || strncasecmp(d.response, resp_hash, strlen(resp_hash))) {

That line fails the comparison. The hashes are different.

I am using this user to authenticate (users.conf):

I am using firefox.

I also noticed that ast_get_http_method(method) returns UNKNOWN.

By: Perssy Llamosas (pll) 2010-05-09 19:53:13

Checked the status of Authenticated managers in SVN, still unfixed.

Is there a way we can push this ahead? I have been using the JSON manager for about a year already in Asterisk 1.6 without problems. The code is quite trivial since I just copied and pasted from the xml manager.

Uploading updated manager.c for Asterisk and Asterisk svn.

By: Leif Madsen (lmadsen) 2010-05-10 11:32:23

Moving this forward by importing into internal issue tracker.

By: Corey Farrell (coreyfarrell) 2015-03-14 16:53:32.825-0500

Is there still an interest in seeing this implemented?  I ask since ARI should be able to serve your need.

By: Perssy Llamosas (pll) 2015-03-15 01:41:31.300-0500

ARI serves the same purpose. It's fine if this gets closed.