How to get current authenticated user

In requeest I have valid access token so user available in beforeRemote as part of ctx

But how can I get userId from inside of function. For example:

model.js

var loopback = require('loopback');

module.exports = function(someModel) {

someModel.getUserId = function(callback) {
    // ??? How ???
    var userId = loopback.request.getUserId();
};

spent 3 hours on it and can't find easy solution... Basically how can I get user ID from any place in the code?

In the beforeRemote, you can find the userId in ctx.res.token.userId
Not sure this is the best solution or not.

Yes I know it.

But what if I need it inside of function? not in hook? Or how can I pass it to the function without using global variables?

Thanks

I am afraid there is no way how to pass the current user to the remoted method. We are working on a solution that will make this possible - see #337

A hacky workaround: use the new header argument source (see strongloop/strong-remoting#104) to get the access-token from the request header, then look up the userId by querying access tokens.

@bajtos

For anyone else having this problem, here is my implementation of the "hacky workaround" suggested by @bajtos . I put this in my server.js file.

// Retrieve the currently authenticated user
app.use(function (req, res, next) {
  // First, get the access token, either from the url or from the headers
  var tokenId = false;
  if (req.query && req.query.access_token) {
    tokenId = req.query.access_token;
  }
  // @TODO - not sure if this is correct since I'm currently not using headers
  // to pass the access token
  else if (req.headers && req.headers.access_token) {
    // tokenId = req.headers.access_token
  }

  // Now, if there is a tokenId, use it to look up the currently authenticated
  // user and attach it to the app
  app.currentUser = false;
  if (tokenId) {
    var UserModel = app.models.User;

    // Logic borrowed from user.js -> User.logout()
    UserModel.relations.accessTokens.modelTo.findById(tokenId, function(err, accessToken) {
      if (err) return next(err);
      if ( ! accessToken) return next(new Error('could not find accessToken'));

      // Look up the user associated with the accessToken
      UserModel.findById(accessToken.userId, function (err, user) {
        if (err) return next(err);
        if ( ! user) return next(new Error('could not find a valid user'));

        app.currentUser = user;
        next();
      });

    });
  }

  // If no tokenId was found, continue without waiting
  else {
    next();
  }
});

This is the workaround I used on a custom route /whoami

    router.get('/whoami', function (req, res) {
        var app = require('../server');
        var AccessToken = app.models.AccessToken;
        AccessToken.findForRequest(req, {}, function (aux, accesstoken) {
            console.log(aux, accesstoken);
            if (accesstoken == undefined) {
                res.status(401);
                res.send({
                    'Error': 'Unauthorized',
                    'Message': 'You need to be authenticated to access this endpoint'
                });
            } else {
                var UserModel = app.models.user;
                UserModel.findById(accesstoken.userId, function (err, user) {
                    console.log(user);
                                       res.status(200);
                                       res.send();
                });
            }
        });
    });

this route is inside /server/boot/root.js

@amenadiel

@amenadiel - thanks for posting your solution! I didn't know about that AccessToken method findForRequest. Here is my solution updated to use that method, which solves my original TODO:

// Retrieve the currently authenticated user
app.use(function (req, res, next) {
  app.currentUser = null;

  // Retrieve the access token used in this request
  var AccessTokenModel = app.models.AccessToken;
  AccessTokenModel.findForRequest(req, {}, function (err, token) {
    if (err) return next(err);
    if ( ! token) return next(); // No need to throw an error here

    // Logic borrowed from user.js -> User.logout() to get access token object
    var UserModel = app.models.User;
    UserModel.relations.accessTokens.modelTo.findById(token.id, function(err, accessToken) {
      if (err) return next(err);
      if ( ! accessToken) return next(new Error('could not find the given token'));

      // Look up the user associated with the access token
      UserModel.findById(accessToken.userId, function (err, user) {
        if (err) return next(err);
        if ( ! user) return next(new Error('could not find a valid user with the given token'));

        app.currentUser = user;
        next();
      });

    });
  });

});

I don't recommend attaching the user to the app object, it will stop working once you have more than one request being handled in parallel.

Setting that aside, here is a simpler solution:

app.use(loopback.token());
app.use(function(req, res, next) {
  app.currentUser = null;
  if (!req.accessToken) return next();
  req.accessToken.user(function(err, user) {
    if (err) return next(err);
    app.currentUser = user;
    next();
  });
});

But as I said, don't do that. It creates a hard to debug bug where Request A sees app.currentUser filled by Request B in case these requests arrive at the server (almost) in parallel.

@bajtos

@bajtos - wow, thank you for taking the time to point this out. To take your advice and avoid this potential (serious) problem, I have attached the currentUser to the request object rather than the app object so that it is specific to the remote context, as follows:

app.use(loopback.token());
app.use(function (req, res, next) {
  if ( ! req.accessToken) return next();
  app.models.User.findById(req.accessToken.userId, function(err, user) {
    if (err) return next(err);
    if ( ! user) return next(new Error('No user with this access token was found.'));
    req.currentUser = user;
  });
});

I tried first using req.accessToken.user(), but user kept being returned as null.

Now, I am able to access this currentUser in all of my beforeRemote hooks via ctx.req.currentUser. I think this should avoid any issues of user B's credentials being available in user A's request, as each request is a different object, thus each request will have the correct user's information.

@mymainmanbrown - this helped a lot, thank you! I am quite satisfied with the end result of this thread.

Small note: your sample above is missing a final next() call after the currentUser is assigned.

@bajtos

@bajtos - thanks for the commit!

@doublemarked - thanks for the catch. Since implementing this in my own project, I've discovered a "more proper" way of doing this, though the steps and end result are the same. Looking through the expressjs docs, I came across the entry on res.locals, which appears to be intended to store session/state data for the current request. Thus, without further ado, here is the code I'm using now, with the next() call:

app.use(loopback.token());
app.use(function (req, res, next) {
  if ( ! req.accessToken) return next();
  app.models.User.findById(req.accessToken.userId, function(err, user) {
    if (err) return next(err);
    if ( ! user) return next(new Error('No user with this access token was found.'));
    res.locals.currentUser = user;
    next();
  });
});

This is parallel-safe and can be access anywhere you have access to ctx or res.

And if you want to use the new context functionality, you can store the user in the loopback context too:

app.use(loopback.context());
app.use(loopback.token());
app.use(function (req, res, next) {
  if (!req.accessToken) return next();
  app.models.User.findById(req.accessToken.userId, function(err, user) {
    if (err) return next(err);
    if (!user) return next(new Error('No user with this access token was found.'));
    res.locals.currentUser = user;
    var loopbackContext = loopback.getCurrentContext();
    if (loopbackContext) loopbackContext.set('currentUser', user);
    next();
  });
});

// anywhere in the app
var ctx = loopback.getCurrentContext();
var currentUser = ctx && ctx.get('currentUser');

@bajtos

Beautiful, thank you guys.

@bajtos What is this new context functionality and where is it documented? It is new as of what version?

@SamuelBonilla

@SamuelBonilla do you have to set any other param in server.js? I have exactly the same code and it's returning null

@renanwilliam

@renanwilliam I don't have other code in serrver.js. getCurrentContext().active.accessToken return null when the user is not authenticated you need to pass the accessToken to the api endponint

maybe 'downgrade' your nodejs to v0.12 and see if the issue existed. You may refer this discussion:
#878 (comment)

For those looking for a solution to finding out the authenticated user in a remote method (now that currentContext is deprecated), the groundwork is laid out at the following link: https://docs.strongloop.com/display/public/LB/Remote+methods#Remotemethods-HTTPmappingofinputarguments

Here is my example snippet:

  MyObject.remoteMethod(
    'myMethod',
    {
      http: {path: '/myMethod', verb: 'get'},
      accepts: [
        {arg: 'someArgument', type: 'string'},
        {
          arg: 'accessToken',
          type: 'object',
          http: function(ctx) {
            return ctx.req.accessToken;
          }
        }
        ],
      returns: {arg: 'someResponse', type: 'string'}
    }
  );
  MyObject.myMethod = function(someArgument, accessToken, cb) {
    // ...
    // accessToken.userId
    // ...
    cb(null, "Response blah blah...");
  }

Any other solution to get current connected user inside the model?

@jankcat

@jankcat Thanks, this example worked perfectly! Exactly what I was looking for after reading too many pages of back and forth on the issue. I couldn't figure this out from the current 3.0 documentation, so I created a pull request to add your example to the documentation.

@ataft

@ataft thank you for the pull request to improve our documentation!

As I commented there, while the example shown in this issue is a valid one, it is also using a different approach than we implemented for context propagation.

Here is a better example:

// common/models/my-model.js
module.exports = function(MyModel) {
  MyModel.log = function(messageId, options) {
    const Message = this.app.models.Message;
    return Message.findById(messageId, options)
      .then(msg => {
        const userId = options && options.accessToken && options.accessToken.userId;
        const user = userId ? 'user#' + userId : '<anonymous>';
        console.log('(%s) %s', user, msg.text));
      });
  };

// common/models/my-model.json
{
  "name": "MyModel",
  // ...
  "methods": {
    "log": {
      "accepts": [
        {"arg": "messageId", "type": "number", "required": true},
        {"arg": "options", "type": "object", "http": "optionsFromRequest"}
      ],
      "http": {"verb": "POST", "path": "/log/:messageId"}
    }
  }
}

I'm probably misunderstanding something here, as I'm pretty new to Loopback. But do the examples above imply that every model method that needs access to the authenticated user must implement this explicitly? This seems like a lot of overhead for an extremely common situation. Is there any way to just make the authenticated user, if it exists, available in ALL remote methods?

I'm probably misunderstanding something here, as I'm pretty new to Loopback. But do the examples above imply that every model method that needs access to the authenticated user must implement this explicitly?

Yes, that's correct - see http://loopback.io/doc/en/lb3/Using-current-context.html

This seems like a lot of overhead for an extremely common situation. Is there any way to just make the authenticated user, if it exists, available in ALL remote methods?

We tried to use continuation-local-storage as a Node.js replacement for ThreadLocalStorage, unfortunately it turned out there is no reliable implementation of CLS available in Node.js land :(

The solution based on "options" argument is the only robust and reliable approach we have found. However, if you can find a better way, then please let us know!

@bajtos

@bajtos Ok, thanks.

I haven't looked under the hood, so not sure how complicated it would be to implement, but one thought would be to offer a setting at the model level that populates the options from request automatically for all methods. It just seems like such a common need — I can't remember ever working on an app where I didn't need access to the user in the controllers (remote methods, in this case). Maybe something like:

// common/models/my-model.json
{
  "name": "MyModel",
  "includeOptionsFromRequest": true,
  ...
}

Coming from 2.x + current context I am not able to port this implementation to the following cases, and the documentations concept is soo confusing...
options object
optionsFromRequest (that is converted) what? Really? What about options not coming from a request but from an internal test run?

.getCurrentContext
.runInContext (for testing)
.set('xx',value)

the example about getting current user

// common/models/my-model.js
module.exports = function(MyModel) {
  MyModel.observe('access', function(ctx, next) {
    const token = ctx.options && ctx.options.accessToken;
    const userId = token && token.userId;
    const user = userId ? 'user#' + userId : '<anonymous>';

    const modelName = ctx.Model.modelName;
    const scope = ctx.where ? JSON.stringify(ctx.where) : '<all records>';
    console.log('%s: %s accessed %s:%s', new Date(), user, modelName, scope);
    next();
  });
};

is not in relation with
2.x middleware, it does not even return current user object but some token and thats it,

  server.middleware('auth', loopback.token({
                                             model: server.models.accessToken,
                                             currentUserLiteral: 'me'
                                           }));

according to #569 is not acceptable since all framework has this very basic foundation to simply have a shorthand for accessing the current user.

Is there an example of middleware or component for 3.x so we can simply, by using options can retrieve currentUser reference? I mean in a large app there are hundreds of remote methods, shall we need to rewrite all of them? I'm sure there is a better way other than messing up the community with bad design and another bad design not even producing a really usable documentation for cases to be replaced easily. Not even a migration guide.

@barocsi

@barocsi I am afraid I don't understand your comment very well. I'll try to answer as best as I can.

What about options not coming from a request but from an internal test run?

.getCurrentContext
.runInContext (for testing)
.set('xx',value)

When you are invoking a method from code (e.g. in a test), you need to build and pass the options object explicitly. For example:

it('does something with current user', function() {
  return User.login(CREDENTIALS)
    .then(token => {
      const options = {accessToken: token};
      return MyModel.customMethod(someArgs, options);
    })
    .then(result => {
      // verify customMethod worked as expected
    });

it does not even return current user object but some token

The options value contain the same token as set by LoopBack 2.x. You can retrieve the current user e.g. by calling options.accessToken.user() method.

I mean in a large app there are hundreds of remote methods, shall we need to rewrite all of them?

Yes, all remote methods that want to access current context must be modified to accept options argument.

The lack of a solution for ThreadLocalStorage is a limitation of Node.js platform. There is some work in progress on this front, but it's still far from getting into a state where it could be used in production. I am highly encouraging you to get involved in the discussion and work in Node.js core, here are few links to get you started:

AsyncWrap public API proposal nodejs/node-eps#18
[async_hooks] tracking issue nodejs/diagnostics#29
and https://www.npmjs.com/search?q=cls-hooked which is using the new API in development

@bajtos

@bajtos - thank you for this information. Two points that aren't entirely clear -

to make use of options, will I need to migrate from LoopBack 2.x to LoopBack 3.0?
Are only operation hooks affected by this issue ('before save', 'after save', etc), or are all remote methods subject to continuation passing issues? (i.e. would I have to update every place where I'm currently referencing req.accessToken?)

@gdeckert

@gdeckert

to make use of options, will I need to migrate from LoopBack 2.x to LoopBack 3.0?

You can pass context via options in LoopBack 2.x as long as you enable this feature, see http://loopback.io/doc/en/lb3/Using-current-context.html#annotate-options-parameter-in-remoting-metadata:

In LoopBack 2.x, this feature is disabled by default for compatibility reasons. To enable, add "injectOptionsFromRemoteContext": true to your model JSON file.

Are only operation hooks affected by this issue ('before save', 'after save', etc), or are all remote methods subject to continuation passing issues? (i.e. would I have to update every place where I'm currently referencing req.accessToken?)

I think the code which can access accessToken directly via the incomingreq object should not need any changes. You can upgrade it to use options.accessToken instead of req.accessToken, but it shouldn't be required. I use "should" because it's hard to tell for me without seeing your code.

Elegant way of getting userId from acccessToken by request object in remote method:

  MyModel.register = function(req, param, cb) {
    var userId = req.accessToken.userId;

    console.log(userId); 
    cb(null, ...);
  };

  MyModel.remoteMethod(
    'register',
    {
      accepts: [
        { arg: 'req', type: 'object', http: {source: 'req'} }, // <----
        { arg: 'param', type: 'string', required: true },
      ]
    }

Navigation Menu

Repository navigation

How to get current authenticated user #569

47 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

How to get current authenticated user #569

Description

Activity

meng-zhang commented on Sep 19, 2014

cajoy commented on Sep 19, 2014

bajtos commented on Sep 20, 2014

bajtos commented on Sep 20, 2014

brainthinks commented on Oct 27, 2014

ffflabs commented on Oct 27, 2014

brainthinks commented on Oct 28, 2014

bajtos commented on Oct 29, 2014

brainthinks commented on Oct 29, 2014

doublemarked commented on Nov 10, 2014

brainthinks commented on Nov 12, 2014

bajtos commented on Nov 12, 2014

doublemarked commented on Nov 12, 2014

47 remaining items

renanwilliam commented on Aug 3, 2016

SamuelBonilla commented on Aug 3, 2016

chinuy commented on Aug 3, 2016

jankcat commented on Nov 2, 2016

yagobski commented on Nov 3, 2016

ataft commented on Jan 12, 2017

bajtos commented on Jan 13, 2017

jmwohl commented on Jan 18, 2017

bajtos commented on Jan 19, 2017

jmwohl commented on Jan 19, 2017

barocsi commented on Jan 28, 2017

bajtos commented on Jan 30, 2017

gdeckert commented on Feb 15, 2017

bajtos commented on Feb 17, 2017

antarasi commented on Feb 22, 2017

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions