Derby.js Authorization

Meanwhile, Derby has its own hub.

Well, today we’ll talk about authorization and restricting access to data. What is better to use everyauth or passport? Is adding authorization difficult? How to restrict access to data? How to separate the application for users and the admin panel within one derby application?

Login

Derby-examples has an example application with authorization on everyauth . As you can see, it is quite easy to implement authorization via twitter, facebook, linkedin, github, etc. But the link derby + everyauth has certain problems with authorization via 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 with derby. For most cases, you can use derby-auth, which is a ready-made authorization module implemented on passport. As you can see, two collections are created in it: auth - where user passwords are located and users - where other user data is located. Why two collections? In derby there is currently no way to restrict access to the fields of an entity (entity is an object in the database with id). Only to the whole entity at once or to the entire collection. This is due to limitations 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 see their passwords. Therefore, we need two collections. This is perhaps the most unpleasant moment at the moment in derby and of course will be fixed in the future.

Data access restriction

We can restrict access to data at the database level (more precisely, at the orm level or 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 plugins are added to derby.
store.allow - this is how we set the rules for restricting access to data. In this case, the rule is to modify the users collection. The returned arguments vary depending on the rules and contain, among other things, a connect session. The function returns bool - access is allowed or not.
There is no documentation on racer-access, but the source code is small, readable, and contains comments.

Client applications

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

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

The templates, styles, and js for them will be respectively in the / views / app - / views / login, / styles / app - / styles / login, / lib / app - / lib / login folders. The browser will load either one or the other application. This is convenient not only in terms of security, but also in terms of reducing traffic.

Materials on Derby

UPDATE: They suggested that there is still a derby-passport , made based on derby-auth