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
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:
In my application, I want to have a column in the _Users table named lastLogin that tracks the last login time of the user. This needs to be set on the server side so that it cannot be manipulated. For example, if the UTC time was sent by the user, then they could simply hijack the request and set whatever time they would like. For an accurate last login time, there needs to be a login callback where I can modify the _Users table to set the last login time.
Another theoretical use case that comes to my mind is utilizing push notifications to notify other users when one particular user logs in via the login callback. For example, let's assume you have a messaging application, similar to Skype, where you have friends. When one friend logs in, the Parse server will call the login callback and check if any of his/her friends are online. If so, they will receive push notifications that the person logging in has just logged in.
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?
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.
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.
Reacted by Benjamin Friedman Wilson and Colin Fruit
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.
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.
Activity
flovilmart commentedon Jul 18, 2017
Did you try beforeSave and afterSave on the _Session class?
addisonElliott commentedon Jul 18, 2017
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?
flovilmart commentedon Jul 18, 2017
Yeah, that would be my assumption as well. Not sure why we don’t allow those. I’ll have a look
flovilmart commentedon Jul 18, 2017
When did you try it? I’m not seeing any limitation that would explicitely prevent the _Session class to have triggers.
addisonElliott commentedon Jul 18, 2017
I just tried it now.
This cloud code:
results in the error when starting the server:
If you go to the file Parse.Cloud.js in cloud-code within the parse server code, these are the lines:
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?
flovilmart commentedon Jul 18, 2017
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.
danielsanfr commentedon Nov 8, 2017
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.
overpod commentedon Dec 7, 2017
I really need this feature
montymxb commentedon Dec 8, 2017
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.
addisonElliott commentedon Dec 8, 2017
@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.
montymxb commentedon Dec 8, 2017
Exactly. It would be a bit more accurate regarding it's intended use as well.
stale commentedon Sep 18, 2018
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.
fmendoza commentedon Oct 22, 2018
Can we have afterDelete working at least?
flovilmart commentedon Oct 22, 2018
@fmendoza feel free to open a PR, and you’ll get what you want
georgesjamous commentedon Oct 23, 2018
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.
flovilmart commentedon Oct 23, 2018
This has been attempted before without success. Feel feee to try again :)
NicksonYap commentedon Dec 25, 2020
A
beforeLogin()trigger has been added starting from v3.3.0:https://docs.parseplatform.org/cloudcode/guide/#beforelogin