Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

parseerror with jsconnect and vanilla 2.1|master branches

2

Comments

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

  • NirgaliNirgali New
    edited August 2014

    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":""})

  • NirgaliNirgali New
    edited August 2014

    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

  • 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

  • NirgaliNirgali New
    edited August 2014

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

  • BleistivtBleistivt Moderator
    edited August 2014

    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.

  • 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...

  • 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)

  • BleistivtBleistivt Moderator
    edited August 2014

    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.

  • 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.

  • 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.

  • BleistivtBleistivt Moderator
    edited September 2014

    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?

  • BleistivtBleistivt Moderator
    edited September 2014

    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(); 
    
  • 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" }

  • BleistivtBleistivt Moderator
    edited September 2014

    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

  • 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)

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

    I may not provide the completed solution you might desire, but I do try to provide honest suggestions to help you solve your issue.

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

  • hichamhicham New
    edited June 2015

    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)

  • BleistivtBleistivt Moderator

    @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');
    
Sign In or Register to comment.