-
Notifications
You must be signed in to change notification settings - Fork 29
multiple hooks / array of hooks #2
Comments
On the actual service you can register as many hooks as you want. Although it's a good idea to also be able to supply an array of hooks on the service object (which would actually be fairly easy). My idea was that you might want to declare cross-cutting concerns not with the service itself but actually in separate modules that are responsible for it (e.g. an Currently you can set up multiple hooks like this: var app = feathers().use('/users', userService);
// We need to retrieve the wrapped service object from app which has the added hook functionality
var userService = app.lookup('users');
userService.before({
...
});
// Somewhere else
userService.before({
...
}); The hooks will run in the order they have been registered. PS: If you want to share, I'd be very interested in a comparison of SailsJS vs. Feathers. |
Sails polices are basically the same as Express middleware. They follow the signature // api/policies/userIsAuthorized.js
module.exports = function (req, res, next) {
if (req.isAuthorized()) {
return next()
}
res.json({ message: 'not authorized' }, 401);
};
// config/policies.js
module.exports.policies = {
UserController : {
'*' : ['userIsAuthorized', 'someOtherPolicy']
}
}; Getting back to your example, the I'm currently thinking along the lines of: var app = feathers.use('/users', userService);
var userService = app.lookup('users');
var auth = require('feathers-auth');
auth.hookup({
service : userService,
before : ['create', 'update', 'patch', 'remove']
}); Or maybe a plugin: var app = feathers.use('/users', userService);
var auth = require('feathers-auth');
app.configure(auth({
'users' : {
before : ['create', 'update', 'patch', 'remove']
}
})); |
Regarding the Feathers vs Sails comparison, is there anything specific you'd like me to go into detail? Sails' scope is a bit broader (Asset Linker, ORM, CLI generator), so it might make the most sense to just compare the parts that both frameworks have in common. |
The easiest thing to implement I think would be: var app = feathers.use('/users', userService);
var userService = app.lookup('users');
var authorize = require('feathers-auth');
userService.before(authorize('create', 'update', 'patch', 'remove')); So // authorization.js
var authorize = require('feathers-auth'); // or your authorization module
module.exports = function(standardAuth) {
standardAuth = standardAuth || ['create', 'update', 'patch', 'remove'];
return function() {
var app = this;
var oldSetup = app.setup;
app.setup = function() {
oldSetup.apply(this, arguments);
// Add standard authorization
_.each(this.services, function(service) {
service.before(authorize.apply(app, standardAuth));
});
// To get user information you always have to be authorized
app.lookup('users').before(authorize('find', 'get'));
// Other custom rules here
}
}
}
// app.js
var authorization = require('./authorization');
var app = feathers();
// ... set up services
app.configure(authorization()); I was just curious about Sails and I know that people love comparison articles (e.g. Sails vs. Feathers vs. Meteor ;). Hoping that there will be a plugin ecosystem around Feathers that provides additional functionality (we already have hooks, associations and some basic service implementations for in-memory services, MongoDB and Mongoose) and maybe a generator that brings it all together. |
I personally think that this syntax is awesome for registering plugin functionality: var authorize = require('authorization-plugin');
userService.before(authorize('create', 'update', 'patch', 'remove')); I really like the function-syntax that is currently in place. I would like to see it extended to work like this, though: // Bring in a file that has a bunch of available hooks for me to pick and choose from.
var hooks = require('../hook-library.js');
service.before({
// non-authenticated users can see records without a userID
index: [hooks.requireAuthAllowPublic],
// Auth is required. No exceptions
create : [hooks.requireAuth, hooks.setUserID, hooks.setCreatedAt]
}); The two syntaxes could be used together, really. If we didn't need to do slightly-modified auth in the example above, but instead wanted to use the authorization plugin on everything: var authorize = require('authorization-plugin'),
hooks = require('../hook-library.js');
// Register the authorize plugin on everything. (So it's first in the queue)
userService.before(authorize('list', 'create', 'update', 'patch', 'remove'));
// Register other custom functionality
service.before({
create : [hooks.setUserID, hooks.setTimestamps]
}); |
Ya I agree with @marshallswain. You could you both syntaxes as it will allow the most flexibility but I think I prefer this one:
|
I've closed the issue as you can now register multiple hooks using the array syntax documented in the README. If we want the plugin-style syntax maybe we can re-open the issue or just create a new issue for it that references this one. |
Awesome! Have a great day! Marshall Thompson On July 20, 2014 at 1:50:19 PM, Eric Kryski ([email protected]) wrote: I've closed the issue as you can now register multiple hooks using the array syntax documented in the README. If we want the plugin-style syntax maybe we can re-open the issue or just create a new issue for it that references this one. — |
How about arrays as another variant to declare hooks? It might be obvious that I'm coming from a SailsJS background, but I'm quite fond of the way policies work.
Would be equivalent to:
For reference: async#applyEach
The text was updated successfully, but these errors were encountered: