Login Callback

[addisonElliott]

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:

1. 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.
2. 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?

[flovilmart]

Did you try beforeSave and afterSave on the _Session class?

[addisonElliott]

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]

Yeah, that would be my assumption as well. Not sure why we don’t allow those. I’ll have a look

[flovilmart]

When did you try it? I’m not seeing any limitation that would explicitely prevent the _Session class to have triggers.

[addisonElliott]

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?

[flovilmart]

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]

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]

I really need this feature

[montymxb]

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]

@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]

Exactly. It would be a bit more accurate regarding it's intended use as well.