Appcelerator ACS.Users.login API Getting error code 400 with message: 'Invalid request sent.'

I am trying to store some data on Custom Object of Appcelerator ACS. So there will be a service to do that. Each time it require authentication to create a new object

But I am sometime getting below error while login with ACS. But it not occuring always. It only if I call service multiple time.

error i am getting is:

{ success: false, error: true, code: 400, message: "Invalid request sent." }

Code used to login :

ACS.Users.login(userData, function(data){
    if(data.success) {
        console.log("----------Successful to login.---------------");
        console.log(data);
        res.send(data);
        res.end();

    } else {
        console.log("------------------login failed---------------");
        console.log(data);
        res.send(data);
        res.end();
    }
},req, res);

Can some one can help me to understand how to re-use session id from node.ACS web service app (Not web app)?

How I can keep session / check session validity before pushing something to custom object? Has anyone faced similar issue?

Thanks Peter

Solution

Since you are passing in the req and res parameters into ACS.Users.login, the session is saved in the _session_id cookie:

http://docs.appcelerator.com/cloud/latest/#!/guide/node_acs

When you make subsequent calls to ACS, you pass in the req and res parameters and it will check for this session token.

A session can become invalid after timeout or logout. To check whether a session is still good, one way is to check against this REST API endpoint (GET):

https://api.cloud.appcelerator.com/v1/users/show/me.json?key=(YOUR ACS KEY)&_session_id=(SESSION ID OF THE USER)

Also, for some reason acs-node v0.9.3 appears to be returning the same session ID, even for different users. Some side-effects I've seen include (1) the wrong user attempting to make a change to an object, and (2) objects created by one user are actually owned by the last person who logged in. Making sure acs-node is at v0.9.2 avoids this issue.