Django-like middlewares including CSRF middleware

[ngaranko]

Hi Evan,

Here's my implementation of django-like middlewares, please see README_MIDDLEWARES for short details(unfortunately doc isn't finished yet, I'm damn bad in this).

CSRF_middleware is incorporated, since it's gonna be used quite frequently.

[davidw]

One small doubt I have about this is that it requires you to track these in boss.config. Currently, we are not tracking boss.config in revision control because it contains local information about the developer's machine, passwords, and stuff like that. I could see things getting confusing by having this contained within that file.

Perhaps the problem is on our end, or maybe the best solution is to have two config files, allowing developers to override options locally... Not really sure.

[ngaranko]

@davidw Same doubts for me, especially because of a fact that boss.config isn't reloaded with app. But I haven't managed to find better place for it, any suggestions?

[Linicks]

Why not just have a second config file in a config directory? Seems simple enough.

[evanmiller]

The question for me is who installs middleware? The developer or the deployer? For example, let's say there is CSRF middleware and a forum application. Is the forum developer responsible for installing CSRF, or will this be left to the person installing the forum?

If the former, this config info is not truly configuration and it belongs in the controller code, e.g. with a -plugin() or -middleware() attribute or something like that. If the latter, then it is configuration, but probably belongs in a separate middleware.config for the reasons @davidw mentioned.

My gut feeling is that deployers should be unaware of controller names and all this should be left to the developer with controller code decorations.

[ngaranko]

Defining -plugin() or -middleware() or what else on controller level will totally kill the idea of easily plugable middlewares, since we already have before_ & after_ which are doing the same.

Separate middleware.conf or even reloadable module with extra configuration for whole boss will do this job.
This can also solve (not just @davidw's) problem with separate configs for dev/testing/prod systems.

[evanmiller]

OK, I see. In that case I think a reloadable priv/middleware.config makes sense. Perhaps the configuration could be overridden in boss.config somehow so that deployers could alter the behavior of an application without modifying its contents.

[ngaranko]

I think it would be wise to have optional priv/development.config that can be fully/partially overridden by boss.config. This will satisfy all our needs.

[kotedo]

Does that mean we have CSRF to our disposal now? w00t! ... ?!

[danikp]

Hi,

it could be nice to have that merged in nearest release, but it seems to be stuck. vote for that pull-request ))

[ngaranko]

@danikp first I need to update this push request from with latest master and verify it works + add a way to separate middlewares config from general, I'll tend to do so this weekend.

[evanmiller]

This is being superseded. See

https://groups.google.com/forum/#!topic/chicagoboss/gpRq3Mozj3c