Restrict Middleware to certain routes..

[Dav Glass]

Is there any predefined way to restrict middleware to run only on
certain routes or to exclude certain routes?

For example, I have a middleware app that reads the request, checks
the users cookies and sets up a session state from a 3rd party app.

However, since it runs on all requests, even requests for static pages
(images, html pages, css files, text files) still have this code
executing.

I would like to limit the middleware to a predefined set of routes, so
that the authentication is only run on routes that I am handling..

I *could* parse the requested URL in the middleware and determine if I
should run the code, but I was hoping there would be an easier way..

Thanks
Dav

--
Dav Glass
davg...@gmail.com
blog.davglass.com

+ Windows: n. - The most successful computer virus, ever. +
+ A computer without a Microsoft operating system is like a dog
    without bricks tied to its head +
+ A Microsoft Certified Systems Engineer is to computing what a
   McDonalds Certified Food Specialist is to fine cuisine  +

[vision media [ Tj Holowaychuk ]]

I dont think anyone has the end-all solution for that sort of thing yet it is usually pretty ad-hoc, but that being said you can "mount" middleware. When you use(someMiddleware()) the mount point defaults to "/", but you can specify by providing a path. For example you could do something like this for private statics:

    app.use(express.regularMiddlewareHere());

    app.get(...);

    app.use('/private', authorizationRequired());

    app.use('/private', express.staticProvider());

In one of the other threads we talked a bit about adding precondition callbacks so it would maybe look something like this, and would be more flexible:

    app.get('/path', authorizationRequired, function(req, res){});

a bunch of intermediate callbacks could be supplied via array or like above, so common use-cases could just be populated in an array somewhere and passed to several routes

--
You received this message because you are subscribed to the Google Groups "Express" group.
To post to this group, send email to expre...@googlegroups.com.
To unsubscribe from this group, send email to express-js+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/express-js?hl=en.

--
Tj Holowaychuk
Vision Media
President & Creative Lead

[Dav Glass]

Nice, I didn't notice the "mount" point for use.. That works for me..

Thanks

--
Dav Glass
davg...@gmail.com
blog.davglass.com

+ Windows: n. - The most successful computer virus, ever. +
+ A computer without a Microsoft operating system is like a dog
    without bricks tied to its head +
+ A Microsoft Certified Systems Engineer is to computing what a
   McDonalds Certified Food Specialist is to fine cuisine  +

[francisco treacy]

Dav,

Good to hear that it works for you. Although I believe that in
general you'll quickly hit a wall - for instance when you use routes
with params (my case, see example below *).

Also, as you suggested, in order not to have to make the route
filtering on the middleware itself, thus repeating yourself... Hence
my API proposal for per-route middleware of a few days ago.

TJ: is this anywhere in the near-term roadmap? I'd like to help. Start
perhaps by opening an issue on github or you keep track of these
features somewhere else?

Francisco

(*)
var app = express.createServer();

app.use('/test/:id', express.logger()) // never logs regardless of route

app.get('/', function(req, res){
res.send('Hello World');
});

app.get('/test/:id', function(req, res) {
res.send('Hello ' + req.params.id)
})

app.listen(3000);

2010/10/6 Dav Glass <davg...@gmail.com>:

[vision media [ Tj Holowaychuk ]]

Yeah a detailed issue would be nice. I have a few thoughts on this. My main concern is making things more complex and increasing the learning curve, and there (IMO) is a certain elegance that comes along with have a WYSIWYG approach to routing aka GET /some/path, but that being said this issue described is a fundamental "flaw" with Connect. We *could* implement these pre-condition callbacks via app.get('/string', fn, fn, function(){ ... }), but this essentially reproduces Connect's dispatcher and only helps the problem at a linear level.

(fab)'s branching model (or similar) would be better suited, although increasing the learning curve and possibly turning people away from the framework all together. There are certainly benefits of each approach, but I think the API needs to be fleshed out at the Connect level as well.

[vision media [ Tj Holowaychuk ]]

This is pretty much the best we could do immediately (which would be quick to implement) http://gist.github.com/614902 but yeah like I said, pretty linear and does not really address the issue over all

[vision media [ Tj Holowaychuk ]]

k, I quickly implemented the idea:

http://gist.github.com/614954

[francisco treacy]

2010/10/7 vision media [ Tj Holowaychuk ] <t...@vision-media.ca>:

> k, I quickly implemented the idea:
> http://gist.github.com/614954

Well yea... that looks great! Seriously, it promises a lot more
flexibility (without going the (fab) route - which is really cool but
is a whole other beast).

IMO this does not increase the learning curve because the basic API
remains the same. You can see this as a bonus, something you need not
to know upfront to get started.

[vision media [ Tj Holowaychuk ]]

haha yeah for sure. I dont think this increases the learning curve either, which is nice, I know taking a more fab-ish approach would increase it quite a bit. This can be optimized in terms of routing, right now to implement it quickly basically all it does is define the same route several times with the middleware given followed by your route callback, calling the regexp's exec() each time which is not ideal performance-wise but that can come in a bit :)

[Ciaran]

'Woot' this is *so* commonly asked for around the connect-auth stuff :)
-cj.

On Thu, Oct 7, 2010 at 12:48 PM, vision media [ Tj Holowaychuk ]

[Rick]

Is this now standard?

I'd quite like to be able to do the following style:

app.get("/hello", function(req,res,next) {
//stuff
}).requiresAuthentication('twitter').allow('member').resitrictAge(18)



(I had just started implementing when I came across this discussion)

> >> >> to implement) http://gist.github.com/614902but yeah like I said,

> >> >>>> 2010/10/6 Dav Glass <davgl...@gmail.com>:

> >> >>>> > Nice, I didn't notice the "mount" point for use.. That works for
> >> >>>> > me..
>
> >> >>>> > Thanks
>
> >> >>>> > --
> >> >>>> > Dav Glass

> >> >>>> > davgl...@gmail.com

> >> >>>> >> On Wed, Oct 6, 2010 at 8:39 AM, Dav Glass <davgl...@gmail.com>

> >> >>>> >>> davgl...@gmail.com

> ...
>
> read more »

[vision media [ Tj Holowaychuk ]]

Yup, will be standard public API now. You could probably implement the chaining still like you show (if you want), since app.get() etc returns the Server, you could extend the proto and probably fiddle around that way

[Aaron Heckmann]

Thats super handy. Great stuff.

Aaron

http://www.learnboost.com
http://clickdummy.net

[vision media [ Tj Holowaychuk ]]

Quick docs for anyone interested http://bit.ly/aJesBb should be pretty nice to have this feature around :D

[francisco treacy]

Beautiful. Thanks!