Rights-middleware
fork from connect-roles
The code is change so it assume the result of a function that is not returning true is falsy. That way I prevent testing of additional rules from the chain, after any of them fails. siply saying that if the user is tested if it is logged and it fails, weshouldn't test for any other rights.
Connect Roles

Connect roles is designed to work with connect or express. It is an authorisation provider, not an authentication provider. It is designed to support context sensitive roles/abilities, through the use of middleware style authorisation strategies.
If you're looking for an authentication system I suggest you check out passport.js
Installation
$ npm install rights-middleware
Usage
var authentication = ;var user = ;var express = ;var app = ; appapp; //anonymous users can only access the home page//returning false stops any more rules from being//considereduser //moderator users can access private page, but//they might not be the only one so we don't return//false if the user isn't a moderatoruser //admin users can access all pagesuser; //optionally controll the access denid page displayeduser; app;app;app; app;
API
roles.use(fn(req, action))
Define and authorisation strategy which takes the current request and the action being performed. fn may return true
, false
or undefined
/null
If true
is returned then no further strategies are considred, and the user is granted access.
If false
is returned, no further strategies are considered, and the user is denied access.
If null
/undefined
is returned, the next strategy is considerd. If it is the last strategy then access is denied.
roles.use(action, fn(req))
The strategy fn
is only used when the action is equal to action
. It has the same behaviour with regards to return values as roles.use(fn(req, action))
(see above).
It is equivallent to calling:
roles;
N.B. The action must not start with a /
character or it will call roles.use(path, fn(req, action))
roles.use(action, path, fn(req))
Path must be an express style route. It will then attach any parameters to req.params
.
e.g.
roles;
Note that this authorisation strategy will only be used on routes that match path
.
It is equivallent to calling:
var keys = ;var exp = ;roles;
roles.can(action) and roles.is(action)
can
and is
are synonyms everywhere they appear.
You can use these as express route middleware:
var user = roles; appapp
req.user.can(action) and req.user.is(action)
can
and is
are synonyms everywhere they appear.
These functions return true
or false
depending on whether the user has access.
e.g.
app
user.can(action) and user.is(action)
Inside the views of an express application you may use user.can
and user.is
which are equivallent to req.user.can
and req.user.is
e.g.
<% if (user.can('impersonate')) { %> Impersonate<% } %>
N.B. not displaying a button doesn't mean someone can't do the thing that the button would do if clicked. The view is not where your security should go, but it is important for useability that you don't display buttons that will just result in 'access denied' where possible.
roles.setFailureHandler(fn(req, res, action))
You can (and should) set the failure handler. This is called whenever a user fails authorisation in route middleware.
Defaults to:
user;
There is no "next" by design, to stop you accidentally calling it and allowing someone into a restricted part of your site. You are passed the action requested which caused them to be denied access.
You could using this to redirect the user or render an error page:
user;
License
MIT
If you find it useful, a payment via gittip would be appreciated.