Skip to content

Login Callback #4020

Closed
Closed

Description

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

Activity

  1. flovilmart commented on Jul 18, 2017

    @flovilmart
    Contributor

    Did you try beforeSave and afterSave on the _Session class?

  2. addisonElliott commented on Jul 18, 2017

    @addisonElliott
    ContributorAuthor

    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?

  3. flovilmart commented on Jul 18, 2017

    @flovilmart
    Contributor

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

  4. flovilmart commented on Jul 18, 2017

    @flovilmart
    Contributor

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

  5. addisonElliott commented on Jul 18, 2017

    @addisonElliott
    ContributorAuthor

    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?

  6. flovilmart commented on Jul 18, 2017

    @flovilmart
    Contributor

    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.

  7. danielsanfr commented on Nov 8, 2017

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

  8. overpod commented on Dec 7, 2017

    @overpod

    I really need this feature

  9. montymxb commented on Dec 8, 2017

    @montymxb
    Contributor

    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.

  10. addisonElliott commented on Dec 8, 2017

    @addisonElliott
    ContributorAuthor

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

  11. montymxb commented on Dec 8, 2017

    @montymxb
    Contributor

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

  12. stale commented on Sep 18, 2018

    @stale

    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.

  13. fmendoza commented on Oct 22, 2018

    @fmendoza

    Can we have afterDelete working at least?

  14. flovilmart commented on Oct 22, 2018

    @flovilmart
    Contributor

    @fmendoza feel free to open a PR, and you’ll get what you want

  15. georgesjamous commented on Oct 23, 2018

    @georgesjamous
    Contributor

    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.

  16. flovilmart commented on Oct 23, 2018

    @flovilmart
    Contributor

    This has been attempted before without success. Feel feee to try again :)

  17. NicksonYap commented on Dec 25, 2020

    @NicksonYap

    A beforeLogin() trigger has been added starting from v3.3.0:
    https://docs.parseplatform.org/cloudcode/guide/#beforelogin

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions