Iron Router Route Allow/Deny - coffeescript

I'm writing a a meteor application right now, and am getting used to the new Iron Router package (as opposed to the router package that I used before).
I have a collection of routes that should only be accessible by users with specific properties. To be specific, I'm using the Roles package. My way of achieving this at the moment is to define a before function that runs a conditional, and redirects to a login or error page if the user doesn't have the proper role. Here's just a quick (coffeescript) example:
this.route 'home',
path: '/'
template: 'dashboard'
before: ->
unless Meteor.userId()
this.redirect 'userUnauthorized'
do this.stop
My question is, is there a better way to do this? It seems like there should be some way to add a permission set, and apply that permission set to a route as opposed to writing the access conditionals for every route.

You could setup a global "Before" in your routes. I'm not using roles in my current app, but we are redirect users globally based on whether or not they are signed in.
You could probably do something like this:
Router.before(function() {
unless(Meteor.userId()) {
this.redirect('userUnauthorized');
do (this.stop)
}
}, {except: ['userUnauthorized', 'otherPageUnauthorizedUsersAllowedToSee']});
We use something similar right below our Router.configure()

Related

Where to put custom advanced queries in a sailsjs mongodb stack

I want to proceed with more advanced queries in a sailsjs and mongodb stack where sailsjs is setup to serve as an api with data against a front end client. I've been able to fetch data with some basic queries but now looking into on how to proceed with more advanced ones. For example, I want to query the database for entries where the string match either the title or the text, something like this,
db.mycol.find({$or:[{"text":/.*test.*/},{"title": /.*test.*/}]})
My question, where do I put this logic? Any hints, links, tutorial that could point me into the right direction for this would be appreciated.
If you generate an api, for example:
sails generate api Customer
Sails will create a CustomerController for you in api>controllers.
You can add whatever custom endpoints you want to that.
If I put in CustomerController
blah: function(req, res) {
res.json(200, 'You are at blah');
}
and I navigate to customer/blah, it will hit that endpoint. So you can add whatever custom endpoints you want to for that controller. Go crazy.
Do not forget that sails has policy enforcement that you need to set up in the config/policies.js. This lets you expose, block, or add whatever middleware you need to in order to keep your back end as secure or open as it needs to be.

EmberAuth actionRedirectable Module prevents use from accessing a resource by URL

I have the following Auth object in my app:
App.Auth = Ember.Auth.create
signInEndPoint: '/users/sign_in'
signOutEndPoint: '/users/sign_out'
tokenKey: 'auth_token'
tokenIdKey: 'user_id'
userModel: 'App.User'
modules: ['emberModel', 'rememberable', 'actionRedirectable']
actionRedirectable:
signInRoute: 'home'
signOutRoute: 'login'
rememberable:
tokenKey: 'remember_token'
period: 7
autoRecall: true
Everything with authentication is working great. The problem I'm seeing now, though, is that when a user attempts to access, say, 'mydomain.com/#/articles/12' and has a valid remember token, accessing the application is tantamoun to starting a new boot of the application. The user is signed in via remember token, and actionRedirectable takes over and takes the user to HomeRoute instead of going to the requested resource.
I feel like I could get around this by manually transitioning the routes in the relvant login/logout controllers, but I wonder if there's a baked in way of solving this in EmberAuth?
ember-auth dev here.
This looks like a known issue. Try the fix in this comment from github issue #69.
In short, module order does matter. actionRedirectable needs to register the route (probably the article route in your case), before rememberable signs in the user and requests a redirect. Otherwise it would have nowhere to redirect to, and falls back to your home route as specified.
There have already been requests of fixing this unexpected behavior, but I haven't been able to find a fix yet - sorry.

Using Everyauth/Express and Multiple Configurations?

I'm successfully using Node.js + Express + Everyauth ( https://github.com/abelmartin/Express-And-Everyauth/blob/master/app.js ) to login to Facebook, Twitter, etc. from my application.
The problem I'm trying to wrap my head around is that Everyauth seems to be "configure and forget." I set up a single everyauth object and configure it to act as middleware for express, and then forget about it. For example, if I want to create a mobile Facebook login I do:
var app = express.createServer();
everyauth.facebook
.appId('AAAA')
.appSecret('BBBB')
.entryPath('/login/facebook')
.callbackPath('/callback/facebook')
.mobile(true); // mobile!
app.use(everyauth.middleware());
everyauth.helpExpress(app);
app.listen(8000);
Here's the problem:
Both mobile and non-mobile clients will connect to my server, and I don't know which is connecting until the connection is made. Even worse, I need to support multiple Facebook app IDs (and, again, I don't know which one I will want to use until the client connects and I partially parse the input). Because everyauth is a singleton which in configured once, I cannot see how to make these changes to the configuration based upon the request that is made.
What it seems like is that I need to create some sort of middleware which acts before the everyauth middleware to configure the everyauth object, such that everyauth subsequently uses the correct appId/appSecret/mobile parameters. I have no clue how to go about this...
Suggestions?
Here's the best idea I have so far, though it seems terrible:
Create an everyauth object for every possible configuration using a different entryPath for each...
Apparently I jumped the gun and wrote this before my morning cup of coffee, because I answered my own question, and it was quite easy to implement. Basically I just had to create my own custom express middleware to switch the everyauth configuration before the everyauth gets its grubby paws on the request, so...
var configureEveryauth = function()
{
return function configure(req, res, next) {
// make some changes to the everyauth object as needed....
next();
};
}
and now my setup becomes:
var app = express.createServer();
everyauth.facebook
.entryPath('/login/facebook')
.callbackPath('/callback/facebook');
app.use(configureEveryauth());
app.use(everyauth.middleware());
everyauth.helpExpress(app);
app.listen(8000);
Notice that I don't even bother fully configuring the everyauth Facebook object during the startup, since I know that the middleware will fill in the missing params.

Redirecting requests form a catch-all controller in Zend Application without looping forever

There are plenty of related posts to what I'm asking, but after some lengthy searches couldn't quite find what I was looking for, my apologies if it exists somewhere.
My goal -- ALL requests to my Zend App must go through a preDispatch plugin, then pass to a custom Auth controller that will decide whether existing auth credentials are sufficient for the requested operation. 'Sufficient' depends on the logic of the app, hence why I want to do this at the controller+model level. If they suffice, they send the original request along to the specified controller+action, if not they default to a 'get lost' action.
At present I'm using an auth custom plugin set in the preDispatch to simply check for POST'ed auth credentials (if we are logging in), then in all cases the plugin stores the original request and redirects everyone (auth'd or not) to my auth controller, a-la:
$request->setModuleName('default')
->setControllerName('auth')
->setActionName('check')
->setParam('oreq',$request->getParams());
My problem/question is that within my auth->check action, how should I perform the redirect after a decision is made? If I use:
$this->_helper->redirector($or['action'], $oreq['controller']);
then I obviously get an infinite loop as these requests pass through the preDispatch plugin again. Sure I could pass something with the redirect so that the Auth plugin ignores such requests, but this is clearly a security hole. I had thought about maybe generating and storing an md5 hash, storing it to session and passing that as an escape param, but that seems a little sketchy.
Any better ideas out there? Perhaps a redirect method that does not go through the standard predispatch routine in Zend App? Thanks in advance!
This is not how it is done usually in Zend Framework. Not all requests go to a common place and gets redirected to the original requested place authentication.
For access control, use Zend_Acl. Through that, you could easily determine whether the current user has the necessary auth to access the content, else redirect to 'get lost' action.
If you are still adamant on using your technique, use _forward method instead of redirect method.
Since _forward is an internal redirect, you could pass additional arguments and check that in preDispath to avoid a loop.
$this->_forward($action, $controller, $module, $params)

How is ACL implemented

i am using Zend_Acl, PHP and is wondering how shld ACLs be implemented.
shld every page be a resource and i always query the acl to see if a user is authorized? i guess i must use this if i want to use a controller plugin (can be setup to run on every request) to check if a user is allowed?
or do i just put the query code where i need it? eg. at the top of pages i need to query the acl? then in pages publicly available, i just skip it? may get troublesome if the application gets big?
ok, i just answer this question then close it
what i did now was have a controller plugin that sets its resource based on controller name and privilege based on action name. then query the acl based on that
still under development, but what i currently have look like http://pastebin.com/9BYzms7W