4

I am trying to build a RESTful API using Node.js w/ Express. I am fairly new to the MEAN stack, and want to use best practices. The concept I'm having trouble grasping and implementing is the following:

Restricting routes like PUT and DELETE on a user object, to only allow requests from users who 'own' this object.

One possibility I've thought of:

Creating secret token for users that matches token in DB

So when creating a user I assign them a token, store this in the DB and attach it to their session data.

Then my middleware would look something like:

router.put('/api/users/:user_id', function(req, res, next) {
  // already unclear how this token should be transfered 
  var token = req.headers['x-access-token'] || req.session.token;

  // update user (PUT /api/users/:user_id)
  User.findById(req.params.user_id, function(err, user) {
    if (err) {
      res.send(err);
    } else if (user.token != token) {
      res.json({ sucess: false, message: 'User not same as authenticated user.' });
    } else {

      // set new information only if present in request
      if (req.body.name) user.name         = req.body.name;
      if (req.body.username) user.username = req.body.username;
      ...

      // save user
      user.save(function(err) {
        if (err) res.send(err);

        // return message
        res.json({ message: 'User updated.' });
      });
    }
});

Questions I have regarding best practice

  • Is the scenario I thought of at all plausible?
  • What data should I use to create a unique token for a user?
  • Is storing the token in the session the best solution?

Sidenote

This is a learning project for me, and I am aware of libraries like Passport.js. I want to learn the fundamentals first.

I have a repo for this project if you need to see some of the surrounding code I'm using: https://github.com/messerli90/node-api-ownership

Edit

I would accept a good RESTful API book recommendation, where these points are covered, as an answer.

Edit 2

I actually found a lot of the answers I was looking for in this tutorial: http://scottksmith.com/blog/2014/05/29/beer-locker-building-a-restful-api-with-node-passport/

I was trying to do this without the use of passport.js but a lot of the concepts covered in the article made some of the mechanics of an authorized API clear to me.

Michael Messerli
  • 95
  • 2
  • 6
  • it's not quite clear to me where the difference between the user id and access token would be in your scenario? – Laura Jan 20 '15 at 11:19
  • @mvuajua if I understand your question. The token being defined is pulled from req.session.token and being compared to the token in the user object. – Michael Messerli Jan 20 '15 at 11:22
  • yeah, but why not use the user id for that (which already exists in the database and is most likely needed in the session)? where do you see the advantage of using an access token? – Laura Jan 20 '15 at 11:25
  • I just assumed that using the Id could be a security risk. – Michael Messerli Jan 20 '15 at 11:26
  • 1
    I personally don't see any risk in that (unless you plan on making the tokens somewhat accessible - do you?), might even be less risky since you could do the check before even querying the database, but maybe someone else with more knowledge can elaborate on that :) – Laura Jan 20 '15 at 11:33
  • @mvuajua ok thanks. Like I said, I'm pretty new to this and wasn't sure how easy it is to spoof session data when you know someone's id. – Michael Messerli Jan 20 '15 at 11:40
  • 1
    as long as the session id is not the user id you should be good, also see [this answer](http://stackoverflow.com/a/5121819/1577453) (php, but same principle) - this is the same for the access token though – Laura Jan 20 '15 at 12:10

3 Answers3

2

If I understand your question, this is an API, and the client (not a browser) is passing the secret token (api key) in the request, in a header. Seems reasonable. Of course, you must require https to protect the api key. And, you should have a way for users to revoke/regenerate their API key.

So far, I don't think you need to store anything in the session. It seems like storing the token in the session just complicates things. Presumably, if you are going to establish a session, the client has to include the token in the first request. So, why not just require it on each request and forget the session? I think this makes life simpler for the api client.

ryanman
  • 3,794
  • 3
  • 25
  • 15
2

A 'bit' too late, but if someone is still looking for an answer, here is how i did it: 

router.put('/', function(req, res) {
    var token = req.headers['x-access-token'];
    if (!token) return res.status(401).send({auth:false, message:'No token provided'});
    jwt.verify (token, process.env.SECRET, function (err, decoded) {
        if(err) return res.status(500).send({auth:false, message:'failed to auth token'});
        User.findByIdAndUpdate({_id: decoded.user_id}, req.body, function(err, user) {
            if (err)
                res.send(err);
            res.json({username: user.username, email: user.email});
        });
    });
});

Just pass the user id that is stored in the token to the mongoose function. This way the user who sent the request can only update or delete the model with his ID.

nicolallias
  • 1,055
  • 2
  • 22
  • 51
Evgenij
  • 21
  • 1
0

Reading material: Implementing Access Control in Node.JS

Found this super clear article on how to allow users to only delete replies they own. Hope it helps.

What worked for me:

.delete(requireAuth, async (req, res, next) => {
    const knexInstance = req.app.get("db");
    const comment = await CommentsService.getById(knexInstance, req.params.id);

    if (comment === undefined) {
      return res.status(404).json({
        error: {
          message: `Comment doesn't exist.`
        },
      });
    }

    if (comment.users_id !== req.users.id) {
      return res.status(401).json({
        error: {
          message: `You can only delete your own comments.`
        },
      });
    }

    CommentsService.deleteComment(knexInstance, req.params.id)
      .then((numRowsAffected) => {
        res.status(204).end();
      })
      .catch(next);
  })
peyo
  • 351
  • 4
  • 15