There’s no need to mention how quickly everyone has adopted Node.js for application development and that too still continues. According to Stackoverflow.com’s survey of 2016, is the most trending technology along with Node.JS gaining significant popularity too. Javascript Also, we can see how many customers use Node.js in production in the stats on the following site https://siftery.com/ . There’re multiple giants using Node.js for their applications some of them are : nodejs Curios what parts they cover using Node.js? Here’s one about how LinkedIn is using Node.js in their application : _This morning, LinkedIn launched its gorgeously overhauled mobile app. We've already told you all about the new features…_venturebeat.com Exclusive: How LinkedIn used Node.js and HTML5 to build a better, faster app While there are a lot of packages/tools you’ll be using developing with Node.js, i.e. Hapi/Koa/Koa2/Express, there’s too which is gaining huge popularity due to its diversity and amazing features. Loopback A little info about Loopback is that it is created by folks at which is an IBM company. It allows you to create strong & flexible APIs and models in no time. Not to mention it has great things to work with i.e. the and available. Strongloop connectors components With that said, lets jump to the ACLs now. ACLs LoopBack uses access control lists (ACLs) to control who can access what data. With ACLs, you can restrict data access to models i.e. the api methods however you want. The way it works is that Loopback uses two collections, and You can create custom roles too but there’re some roles which loopback itself provides out of the box. I.e. $everyone, $authenticated, $unauthenticated etc. Role RoleMapping. Lets assume that you have a customer support application having following models: AppUser (extended from User) Categories We’ll create some custom roles (in boot/script.js): // Assuming...// employeeUsers[] contains the employees// adminUsers[] contains the admins Role.create({ name: 'admin' }, function(err, role) { if (err) cb(err); adminUsers.forEach(function(admin){ //make bob an admin role.principals.create({ principalType: RoleMapping.USER, principalId: admin.id }, function(err, principal) { cb(err); }); }); });Role.create({ name: 'employee' }, function(err, role) { if (err) cb(err); Suppose we have the following apis : Get categories = GET /api/categories Get category by id = GET /api/categories/:cat_id Create category = Post /api/categories We want that only the admin can access ‘Get categories’ call and the authenticated users (employees) should access the ‘Get category by id’ call however employees should not be allowed to a category. So here’s what we’ll do. We’ll use the loopback’s generator to create an ACL. create First, deny access to the categories api for everyone $ lb acl ? Select the model to apply the ACL entry to: Category? Select the ACL scope: All methods and properties? Select the access type: All (match all types)? Select the role: All users? Select the permission to apply: Explicitly deny access Next, we’ll allow the admin to access all the category api. $ lb acl? Select the model to apply the ACL entry to: Category? Select the ACL scope: All methods and properties? Select the role: other? Enter the role name : admin? Select the permission to apply: Explicitly grant access Next, we’ll allow only the employee to access the category by id call. $ lb acl ? Select the model to apply the ACL entry to: Category? Select the ACL scope: A single method? Enter the method name: findById? Select the role: other? Enter the role name : employee? Select the permission to apply: Explicitly grant access After executing the above commands, the ACLs in our category.json should look like this : "acls": [ { "accessType": "*", "principalType": "ROLE", "principalId": "$everyone", "permission": "DENY" }, Conclusion The summarized key-points about ACLs implementation are as follows: Have the User and Role mapped under RoleMappings (image attached below) Have the ACLs setup in the models as per requirements RoleMappings containing principalId as userId, principleType as RoleMapping.USER ('User') The way loopback lets you handle the ACLs is quite sleek. I personally liked it when I got a hang of it.
