parseerror with jsconnect and vanilla 2.1|master branches

Bleistivt

that seems weird, what's in the callback parameter of the test url?

Nirgali

the result of the test url is test({}"email":"email(at)domain.com","name":"Nirgali","photourl":"","uniqueid":"2","client_id":"11111111","signature":"1a1a1a1a1a1a1a1a1a1a1a1a1a")

If I log out of concrete5 the result of the test url is
test({"name":"","photourl":""})

again, while logged into concrete5, I pulled the request from the concrete5 access logs and called it manually. The result was this
jQuery111111111111111_11111111111111({"name":"Nirgali","photourl":""})

Nirgali

The real callback was this http://domain.com/index.php/jsonp?client_id=1111111111&Target=%2F&callback=jQuery111111111111111_11111111111111&_=11111111

The test callback was this http://domain.com/index.php/jsonp?client_id=11111111111&timestamp=1409456533&signature=1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a1a&Target=%2Fsettings%2Fjsconnect&callback=test

Bleistivt

While the JSON is valid, this is not a valid JSONP callback as the function jQuery111111111111111_11111111111111 obviously doesn't exist.

Somehow the client_id and signature appears in the callback name.
The http query is built in a wrong way.

Which version of the jsConnect plugin are you using?

If you are using the one of the addons repo, try this:
https://github.com/vanilla/addons/tree/master/plugins/jsconnect
and vice versa

Nirgali

Same results with the repo version and 1.4.1 release. Client version from repo as well (@version 1.1b).

Bleistivt

What functions are you calling from concrete5?
Maybe the parameters for WriteJSConnect() are somehow switched with the ones for SignJSConnect().
edit: just saw you already posted it above.

Inspect what's in your $_GET array for "callback" on the concrete5 side when you try to sign in.

Nirgali

Yeah I printed that in this reply I tried looking but didn't find where it is sending that function. Are we tumbling down a rabbit hole?

I've been staring at this code for a while. I can't make sense of it. If it works for other people...

Nirgali

To update version information in the OP. I am running with the latest git repo code for jsconnect and the vanilla 2.1.1 release. I tried a fresh installation of vanilla from master but there was a crippling bug preventing me from setting up connection while also allowing a confirmation login (the unconfirmed role drop down wasn't populated)

Bleistivt

A var_dump() of the $_GET from concrete5 without the sensitive data might be helpful.

But with your problem you are better off asking someone who knows about the inner workings of jsconnect, e.g. @todd

Edit: It looks like a problem on the side of your CMS though.

Nirgali

Yeah, Todd is too busy with executive stuff to worry about an addon. As I'm not interested in paying for support, I'll just continue hacking away at the code until I find something. I don't believe the issue is with the CMS because it spews forth the correct json.

Nirgali

One thing to note is that the numbers I masked as 11111111111 are all different. The client_id, the signature, and the numbers in the oddly formed callback function are all different. The client_id and signature match what I have in the config.

Bleistivt

Ah, you censored them!
There is no need however as the callback name is just a random string, as far as I know.

However, there is a lot of information missing in what you get from concrete 5
Now I have no idea how the userobject creation in that cms works, but this looks weird to me:

global $u; //$u is now the global userobject
if ($u->isLoggedIn()) { //you check if the user is logged in
    $u = new User(); //You redefine $u as an NEW user object. Is it still your user?
    $uid = $u->getUserID(); //You get the id of the newly created user object
    $ui = UserInfo::getByID($uid); //you retrieve the UserInfo of the newly created userobject

What happens when new User() is called in concrete 5? Is that User object actually your (the currently active) user?

What happens, if you remove that line?

Bleistivt

http://www.concrete5.org/documentation/developers/permissions/users
Ok, just found here, that new User(); actually return the current user in concrete 5

http://vanillaforums.org/discussion/comment/214371/#Comment_214371
The second response you posted here looks, like the UserInfo object is not working. And the unique_id is missing.

Like I said before, you can only be sure if everything is set correctly if you log what you pass to jsConnect:

ob_start();
var_dump($test);
file_put_contents('log.txt', ob_get_contents());
ob_end_close(); 

Nirgali

The user part of it is working fine. This bit really has me concerned. I don't really like how jsconnect is passing that strange looking callback and the jsonp.php doesn't handle it well. Does this look normal to you?

array(4) { ["client_id"]=> string(10) "1268093700" ["Target"]=> string(1) "/" ["callback"]=> string(41) "jQuery172008153949305415154_1409800475907" ["_"]=> string(13) "1409800476173" }

Bleistivt

That is a perfectly normal callback name for jsonp. jQuery creates that function and calls is once to retrieve the json data.

"parsererror" is not a Vanilla error, but a jQuery error.

Such an error typically appears when jQuery is expecting jsonp but gets json or the other way around.

Are you trying to implement cross-domain SSO? If not, you don't actually need jsonp.
edit: just saw, jsconnect uses it anyway

Could you verify in your browsers network console that the adress actually outputs a javascript file and not html?

Check if the mime type is application/javascript

Nirgali

Good call. "Resource interpreted as Script but transferred with MIME type text/html"

I added "header('content-type: application/javascript; charset=utf-8');" to my jsonp.php and that error went away.

I thought the content-type solution wasn't working at first but I figured out that the automatic email obfuscater addon I installed last night was breaking SSO. I spent four hours today troubleshooting this. Your solution would have worked right away but damn me for being so adventurous with free addons.

Finally I can put this thing to rest!

Thanks for all the valuable feedback everyone! Bleistivt wins for sticking it out and ultimately leading to such a simple solution! +1

For everyone else who encounters this issue. All of the information in this thread is helpful in troubleshooting most issues, not just jsconnect+concrete5 issues. If that is what brought you here, make sure you pass that application/javascript header as the first line in your authentication code or you will repeatedly hit your head on the wall (a prospect that might be less painful than chasing ghosts for days on end)

peregrine

@Nirgali

maybe you want to write a summary tutorial of how to do it (emphasizing the gotchas as well).

Nirgali

@peregrine That is my intention. I just need the time to do it from scratch again to make it fresh in my memory.

hicham

Hi Nirgali, Bleistivt, I have EXACTLY the same problem. I debugged the code up to the point where the line returning something weird is WriteJsConnect, returning:

jQuery17206694520944729447_1435168318521({"uniqueid":"123","name":"John PHP","email":"john.php@anonymous.com","photourl":"","client_id":"237105678","signature":"c07caf45gf62caae2615b754bc3f22c40"})

which of course jQuery doens't like... Vanilla returns "Whoops! parseerror" @Nirgali how did you solve that?!?

(I don't need a clean/robust solution)

Bleistivt

@hicham jQuery doesn't like it because you are probably not setting application/javascript as mentioned above:

header('content-type: application/javascript; charset=utf-8');