Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Django-like middlewares including CSRF middleware #256

Closed
wants to merge 17 commits into
from

Conversation

Projects
None yet
6 participants
Contributor

ngaranko commented May 3, 2013

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.

Contributor

davidw commented May 17, 2013

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.

Contributor

ngaranko commented May 17, 2013

@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 commented Jun 15, 2013

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

Contributor

evanmiller commented Jun 19, 2013

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.

Contributor

ngaranko commented Jun 19, 2013

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.

Contributor

evanmiller commented Jun 19, 2013

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.

Contributor

ngaranko commented Jun 20, 2013

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.

Contributor

kotedo commented Jul 18, 2013

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

Contributor

danikp commented Sep 4, 2013

Hi,

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

Contributor

ngaranko commented Sep 4, 2013

@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.

@ngaranko ngaranko closed this Oct 8, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment