You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently in all my CloudCode functions I would run the following code:
let currentUser = request.user;
let token = currentUser ? currentUser.getSessionToken() : null;
if (!request.master && (!currentUser || !token)) {
response.error(JSON.stringify({
code: kcError.ErrorCodes.ERROR_UNAUTHENTICATED,
message: 'Unauthenticated user.'
}));
return;
}
Subsequent queries, saves and deletes in the CloudCode functions are all carried out with {useMasterKey: true} instead of {sessionToken: token}. Reason is that we consistently found that running query with master key is significantly faster than with session token (5X to 10X), even though we need to construct a much more complicated query with master key. The performance here probably relates to how many roles we have (11.5K for us). If anyone is having a performance drop migrating from Parse.Com to your own server, I recommend checking this. After we switched most of our business logics to run with masterKey (on both Parse.Com and our own Parse Server), our own Parse server is actually much faster than Parse.com (kudos to the contributors of this project. Simply amazing!)
I use the above code to make sure that the CloudCode is called by a valid logged-in user with a valid session token. My questions are:
Do my codes actually achieve my goal, i.e. token is a sessionToken that actually matches a session in my database? Does this make sure that it wouldn't be someone calling the CloudCode with a random, invalid string as sessionToken? Issue A workaround for all current Parse security features (CLP/PLP/ACL) #1013 talked about this but not strictly in the context of CloudCode.
Is request.user guaranteed to reflect data from the database, or is it simply something sent by the client? I relied on the values of currentUser for many of my queries.
The text was updated successfully, but these errors were encountered:
Can you please add all the info specified in the template? This is necessary for people to be able to understand and reproduce the issue being reported.
Currently in all my CloudCode functions I would run the following code:
Subsequent queries, saves and deletes in the CloudCode functions are all carried out with {useMasterKey: true} instead of {sessionToken: token}. Reason is that we consistently found that running query with master key is significantly faster than with session token (5X to 10X), even though we need to construct a much more complicated query with master key. The performance here probably relates to how many roles we have (11.5K for us). If anyone is having a performance drop migrating from Parse.Com to your own server, I recommend checking this. After we switched most of our business logics to run with masterKey (on both Parse.Com and our own Parse Server), our own Parse server is actually much faster than Parse.com (kudos to the contributors of this project. Simply amazing!)
I use the above code to make sure that the CloudCode is called by a valid logged-in user with a valid session token. My questions are:
Do my codes actually achieve my goal, i.e. token is a sessionToken that actually matches a session in my database? Does this make sure that it wouldn't be someone calling the CloudCode with a random, invalid string as sessionToken? Issue A workaround for all current Parse security features (CLP/PLP/ACL) #1013 talked about this but not strictly in the context of CloudCode.
Is request.user guaranteed to reflect data from the database, or is it simply something sent by the client? I relied on the values of currentUser for many of my queries.
The text was updated successfully, but these errors were encountered: