Derby.js Log in

Meanwhile, Derby has its own hub.

Well, today we will talk about authorization and data access restriction. Which is better to use everyauth or passport? Is it difficult to add authorization? How to restrict data access? How to divide the application for users and admin panel within a single derby-application?
')

Authorization

In derby-examples there is an example of an application with authorization for everyauth . As you can see, it is quite easy to implement authorization via twitter, facebook, linkedin, github, etc. But the ligament derby + everyauth has certain problems with authorization through login-password, due to the fact that everyauth is strongly tied to express. Although everyauth was written by one of the creators of derby (long before derby), using this module specifically for derby is not entirely convenient. It happens. Therefore, the recommendation is to use passport , which, due to its architecture, fits better into derby. For most cases, you can use derby-auth , which is a ready-made authorization module implemented on passport. As you can see in it, two collections are created: auth - where the users' passwords are located and users - where the rest of the user data is located. Why two collections? In derby at the moment there is no possibility to restrict access to the fields of an entity (entity is an object in a database with an id). Only to the whole entity at once or to the entire collection. This is due to restrictions in share.js. That is, within the same users collection, we cannot allow the user to see the names of other users, and at the same time, not to see their passwords. For this we need two collections. This is perhaps the most embarrassing moment at this time in the derby and will certainly be corrected in the future.

Data Access Restriction

We can restrict data access at the database level (more precisely, at the level of the orm or the store object) using the racer-access module. In it, you can use sessions from connect to identify users. Used like this:

var racerAccess = require('racer-access'); derby.use(racerAccess); store.allow('change', 'users', function (some usefull arguments) { return true || false; }); 

derby.use - this is how derby plugins are added.
store.allow - so we set the rules for restricting access to data. In this case, the rule for changing the users collection. The returned arguments differ depending on the rules and contain, among other things, the connect session. The function returns bool - whether access is allowed or not.
There is no documentation on racer-access, but the sources are small, readable and contain comments.

Client applications

We did authorization and limited access to data. But what if we don’t want to send templates, styles and logic from the admin to the user's browser? We can split our client application into several. Here is an example of two client applications - app and login. And this - they are in the form of objects on the server.

 login = require('../login') main = require('../app') 

Templates, styles and js for them will be respectively in folders / views / app - / views / login, / styles / app - / styles / login, / lib / app - / lib / login. Either one application or another application will be loaded into the browser. This is convenient not only in terms of security, but also in terms of reducing traffic.

Derby materials

UPDATE: Prompted what else there is derby-passport , made based on derby-auth