A feature that may be useful to add is a login callback (or trigger if you will). When a user logs in with their username and password, this callback will be called in a similar fashion that the triggers beforeSave, afterSave, etc are called.
Let me give you two potential use cases for this:
I have no problem adding this code myself since I think that it will be fairly easy (think being the keyword).
I wanted to get some thoughts/comments on this feature before I write the code for it. Is it worthwhile to have this capability?
Did you try beforeSave and afterSave on the _Session class?
Yes I did and honestly, I thought it was a brilliant idea until I found out that you cannot have triggers on the _Session class.
There is an exception thrown along the lines "Triggers are not allowed on the _Session class." I am not sure what the reasoning behind this.
Instead of a login callback function, would it be more beneficial to allow triggers on the _Session class?
Yeah, that would be my assumption as well. Not sure why we don鈥檛 allow those. I鈥檒l have a look
When did you try it? I鈥檓 not seeing any limitation that would explicitely prevent the _Session class to have triggers.
I just tried it now.
This cloud code:
Parse.Cloud.beforeSave(Parse.Session, function(request, response)
{
console.log("Test!");
});
results in the error when starting the server:
parse-server\lib\cloud-code\Parse.Cloud.js:14
throw 'Triggers are not supported for ' + className + ' class.';
^
Triggers are not supported for _Session class.
If you go to the file Parse.Cloud.js in cloud-code within the parse server code, these are the lines:
function validateClassNameForTriggers(className) {
const restrictedClassNames = [ '_Session' ];
if (restrictedClassNames.indexOf(className) != -1) {
throw `Triggers are not supported for ${className} class.`;
}
return className;
}
function getClassName(parseClass) {
if (parseClass && parseClass.className) {
return validateClassNameForTriggers(parseClass.className);
}
return validateClassNameForTriggers(parseClass);
}
Someone intentionally put a restriction on the class name for sessions. Do you have any idea why? Is there any repercussions to having triggers on the session?
Yeah, allowing to mutate the objects in the session would probably be bad, this is why we probably restricted it originally, we can probably lift the restriction as this would probably work for you.
Anyone have any ideas how to solve this problem? I would be very happy if this worked.
I need an application to have only 1 session per user and I can not do this in a way that I believe is safe.
I really need this feature
Since the basis for this was to get a callback after login, and messing with Sessions post login isn't so great, we could consider an afterLogin hook in cloud code. Similar to how beforeSave and afterSave are hooked into the flow of saving/updating an object, we could integrate this as check to call function before returning on successful login. It might require a little more playing with, but we could be safe not messing with hooks on _Session.
@montymxb Not a bad idea. I think either way will work and I can look into that. It may fit together because then triggers could be added for before email verification, after email verification, etc.
Exactly. It would be a bit more accurate regarding it's intended use as well.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Can we have afterDelete working at least?
@fmendoza feel free to open a PR, and you鈥檒l get what you want
How about allowing Read Only triggers on _Sessions ?
beforeSave: could then be used to mimic a beforeSuccessfullLogin hook. (either throw to reject login or nothing to accept it)
afterSave: editing object at this point is no different from querying and editing it. So it's pointless to have any restriction here.
beforeDelete: we would disregard any thrown error or changes. No point preventing a user from logging out.
afterDelete: has no effect on workflow
I guess changes to achieve this are straightforward, shouldn't require a lot of refactoring.
This has been attempted before without success. Feel feee to try again :)
A beforeLogin() trigger has been added starting from v3.3.0:
https://docs.parseplatform.org/cloudcode/guide/#beforelogin
Most helpful comment
@montymxb Not a bad idea. I think either way will work and I can look into that. It may fit together because then triggers could be added for before email verification, after email verification, etc.