Access restriction to model attributes

[obrienmd]

From: https://groups.google.com/forum/?fromgroups=#!topic/sailsjs/AM452zgLH-Y

As I understand policies allow restriction of viewing specific models. It would be important for larger apps to provide more granularity here, and allow restriction of viewing specific attributes/properties of a given model based on a policy.

[mikermcneil]

Hey @obrienmd, you can do this with custom controllers currently, but I agree being able to do this with policies and the blueprint controllers would be an awesome enhancement. What do you propose for how it would look?

I'd like to avoid putting ACL config directly in the model files, at least in the core, since we want auth/ACL to prevent access before ever hitting any controllers, so it would probably make sense for this to live in config/policies.js. What do you think?

[obrienmd]

Right - I'd considered custom controllers, but then we're losing a good amount of the magic that makes sails awesome. @kevinob11 and I have discussed this a bit, let me talk to him in person and we'll get some more concrete thoughts in here.

[mikermcneil]

@obrienmd Righto-- IMO, the first steps for Sails have been laying down the basics (hitting parity with the Rails core). Beyond that, there are some really neat options we can get into to automate the things we'd normally have to write custom code to do (e.g. using an SMTPAdapter with the blueprint API to send emails, or using the TwitterAdapter to fetch tweets, trends, or locations depending on the model) This fits perfectly into that roadmap :)

[kevinob11]

Just talked to @obrienmd. I'm thinking that most of the work would need to be done in the controllers. My use case is to allow access to the model still, but just prevent access to specific fields within that model. For example we want to return a list of users, but block access to just the password field. I think the config for this could fit into policies or model config, but the work to exclude the fields would need to be done in the controllers.

I haven't looked at all, but I'm also wondering if per field policy (while still configured in either policy or model files) could be handled in waterline.

I'm still just digging into to all this, so I'd love your thoughts on it, and @obrienmd and I will continue to discuss as we learn more.

[mikermcneil]

Waterline should not be in the business of access control, IMO-- in my experience, it's safest to run the ACL at the route/policy/controller level, because then you're explicitly blocking access to a public endpoint. As for partial access, I definitely see the limitations though, particularly if you're trying to rely mainly on blueprints.

Maybe what we could do is look at a nice clean way to do [select operations](http://en.wikipedia.org/wiki/Selection_(relational_algebra) via the Waterline query interface, and then consider the best way to handle that automatically in blueprints?

[particlebanana]

So I think I have a pretty elegant solution to hiding attributes in blueprints. I agree that access control shouldn't be at the data level and instead at the policy level but we also need a way to restrict certain attributes in an api. You don't want an encrypted password sent back in the api for instance.

In the new waterline you have model level instance methods. This poses a problem when serializing the attributes to JSON. So I can add a default .toJSON method on a model instance that gets returned from a query that the blueprints can call before returning the data in a response.

With instance methods, if you want to restrict an attribute you can just override this in the model. I'm not sure what the toJSON method would look like just yet but something along the lines of copying Mongoose like this:

Waterline.Model.extend({
  attributes: {

    // Some model attributes
    username: 'string',
    password: 'string',

    // An instance method that overrides the default
    toJSON: function() {
      var obj = this.toObject();
      delete obj.password;
      return obj;
    }
  }
});

Which would return an object with only the username and can then be used with req.json(model_instance.toJSON()) in the blueprint.

[obrienmd]

+1 on keeping Waterline out of the access control business to the extent possible.

Powerful selects makes sense, the 'best way to handle that automatically in blueprints' is going to be the hard part :)

[mphasize]

I am trying to keep the magic of blueprint controllers while at the same time protecting some model attributes from being changed by users on the default routes.
I.e.: prevent access to the is_admin attribute on regular CRUD routes and implement a promote action or something similar on the UserController which makes the neccessary checks.

In order to do this, I came up with the following policy in combination with a small addition to the model definitions:

// file: api/policies/protectedAttributes.js

/**
 * protectedAttributes
 *
 * @module      :: Policy
 * @description :: Simple policy to protect certain attributes as returned by Model.protectedAttributes()
 * @docs        :: http://sailsjs.org/#!documentation/policies
 *
 */

var actionUtil = require( '../../node_modules/sails/lib/hooks/blueprints/actionUtil' );

module.exports = function ( req, res, next ) {

    var Model = actionUtil.parseModel( req );

    if ( Model.protectedAttributes ) {
        var attributes = Model.protectedAttributes();
        _.each( attributes, function ( attr ) {
            if ( req.params.hasOwnProperty( attr ) ) {
                delete req.params[ attr ];
            }
            if ( req.query.hasOwnProperty( attr ) ) {
                delete req.query[ attr ];
            }
            if ( req.body.hasOwnProperty( attr ) ) {
                delete req.body[ attr ];
            }

        } );
    }
    return next();
};

Inside a model I add the following function as a class method:

protectedAttributes: function () {
    return [ "is_admin", "email_verified" ];
},

So whenever I enable this policy on a route it reads the protected attributes and simply deletes all matching parameters from the request. The solution still feels a bit crude to me, but I get the behavior I want out of it. Any thoughts?

Cheers! Marcus

[mikermcneil]

@mphasize thanks a lot for posting, that looks awesome! feel free to continue this discussion in stackoverflow or the google groups, we're cleaning house up in here

[albertpeiro]

What about output policies @mikermcneil? Similar to the current policies but applied only after the controller pass, and before the response gets sent. Separating them would make sense as they're not the same and the workaround from @mphasize seems quite close to a solution, though it's just not clean.

To me it sounds like a powerful idea to have, it's one of the biggest things I'm missing at the moment. Being able to modify the response on a different layer than the actual controller and apply this policy on a controller basis (same as current).

It may seem like the use case is small, but I find when trying to do any medium size project this comes up as a requirement. It actually comes up as a requirement way way earlier when we need to build a backoffice and modify protected attrs only from certain controller.

Any thoughts?

[albertpeiro]

These seem related:

• regarding old issue #2423
• Access restriction to model attributes #352
• Decorate models #2729

[RWOverdijk]

This should be done upon select, not response. It's overhead per-row. It's not needed.