it's last:
I don't know how to provide order of processing outside middlewares...
i stopped on this:
settings.py:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.Authenticatio
here's my crutch (just for the idea illustrating):
pre-pre-pre-alpha :)
settins.py
MIDDLEWARE_CLASSES = (
'middleware.handlers.Handler', # only first. it's posthandler
processor builder
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddlew
megathanks to all
I will try to use something like:
(r'^members/', include('members.urls'), {'auth':True})
but {'auth':True} will consist of name of handler (handlers)
I'll try to create 1 middleware to process this filters. All handlers
will be called according by its names.
Yes, this is a cru
Oh, forgot there are also signals that might help.
http://docs.djangoproject.com/en/dev/ref/signals/#module-django.core.signals
:)
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googl
Not sure if this would solve the problem, but have a look at
django.utils.ddecorators.decorator_from_middleware.
"""
Given a middleware class (not an instance), returns a view decorator. This
lets you use middleware functionality on a per-view basis.
"""
This also might be best discussed on djang
Hi Serg,
(replying to the list)
On Thu, Nov 26, 2009 at 4:09 AM, serg wrote:
>
> hmm.. yes. it's almost the same i mean.
> but, all middlewares calls for each request... It's bad (imho).
> also in 99.99% cases it wil be work nice...
> thanks!
>
> This method {'filter_ip':True} is unsafe.
>
> Loo
On Wed, Nov 25, 2009 at 11:08 PM, serg wrote:
>
> For example:
you can already do something like this (middleware conditional on
urls) via the view middleware mechanism.
in urls:
...
(r'^members/private/', include('members.private.urls'), {'filter_ip':True}),
...
then the middleware:
class Fil