Distinguish between a sign up and a login

[ryantomaselli]

Hey guys;

When a user registers I would like to create a record in my own database, so I need to be able distinguish between login and sign up.

Perhaps I could change the post login callback URL.

For example I could add the following to the allowed callback URLS
https://localhost:3000/callback, https://localhost:3000/register

And then add rule with a code snippet like this:

  if (context.stats.loginsCount === 1) {
    context.redirect = {
      url: "https://localhost:3000/register"
    };
  }

This does seem to work in terms of the redirect but I would like the URL to also contain all the information that normally comes back with the regular login callback (things like access token, id token etc.)

Will I need to manually build up this URL to include this information? Is this even the right approach?

Any pointers appreciated.

Thanks!

[mathiasconradt]

In case you’re using database connection (and not federated / social logins):

Instead of putting the logic in a Rule (which gets executed upon user authentication), you could instead use a post-user registration hook, which is only called upon signup and which you can use to call your backend.

Post-User-Registration Extensibility Point

Implement Custom Actions Using Post-User Registration Extensibility Points

In case above doesn’t work because you’re not just using database connections, and would go with a Rule: why not create the record (based on loginsCount as you do) directly from within the Rule (via an authenticated API call to your backend that creates the record in your db). Then you don’t need to fiddle around with the redirect URL.

Changing the redirect URL is not necessary and also seems to be the wrong approach especially because the writing to your database does not require any kind of user interaction, which is the scenario that such redirect is intended for.

[ryantomaselli]

Thanks @mathiasconradt for the prompt and detailed response.

Using the post-registration hook seems like a good way to go in my case…

My one thought though was given this is asynchronous I wouldn’t know when the new record in my own database had been created. If I was to query the new database record at the time of the post-authentication callback there is no guarantee that the record has been created yet.

I also wouldn’t know if the database record creation succeeded or not.

[mathiasconradt]

Yes, you are right about that. In that case, if you need a confirmed response back synchronously, you might be better off with the rule, just remember that a rule is trigger on authentication, not on signup.

That means, if you create a user in other ways (i.e. via Management API) than the user himself via the Auth0 Login/Signup page, the system wouldn’t notice it until the user logs in for the first time. But of course, for such cases where you create users differently, you are in control of the user creation process anyway and could take care of the call to your database in other ways.

[ryantomaselli]

Alright, sounds good. I’ll go with the rule then.

Just so others can see what I did here it is, works like a charm:

function (user, context, callback) {
  var request = require('request');
  if (context.stats.loginsCount === 1) {
      request({
        method: 'POST',
        url: 'https://yourapiurl/organizations',
        json: {
          "name": user.user_metadata.organization
        }
      },
      function(err, response, body) {
        if (err) {
          console.log('err: ', err);
          callback(err);
        } else {
          console.log('Organization record created successfully', body.id);
          user.user_metadata.organizationId = body.id;
          context.idToken[configuration.NAMESPACE] = {
            organizationId: body.id
          };
          auth0.users.updateUserMetadata(user.user_id, user.user_metadata)
          .then(function(){
            callback(null, user, context);
          }).catch(function(err){
            callback(err);
          });
        }
      });
  } else {
    callback(null, user, context);
  }
}

[ryantomaselli]

Interesting…I think it is a scoping issue (which is confusing) but when I remove the callbacks from the request callback and just have it always callback things succeed.

So perhaps when I’m calling from inside my request callback the user and context are not scoped and so an erroneous values are passed back or perhaps even callback is not in scope