middleware

[NISA BALAKRISHNAN]

how to write a middleware that that stores all database requests.
How can i store all database requests?

pls help

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

middleware

[Anderson]

Does anyone know if is possible execute a middleware only to a specific
application or url?

-- 
Anderson Dias Borges
Senior Analyst Developer

Tu cumprirás o desejo do meu coração se eu Te buscar...
I can't see but I'll take my chances
To hear You call my name

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

middleware

[Pawanesh Gautam]

why middleware is required ?? 

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/b160c03e-a9c2-42f9-a95e-52fbace330c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Middleware problem

[Josh]

I created a custom middleware for logging requests based on this blog
post: http://whijo.net/blog/brad/2007/07/19/statistics-logging-django.html

It's mostly working fine except for one thing. It causes problems when
a URL without a trailing / is requested. In that case it gives me the
following error:
  File "/home/bostonchefs/webapps/django/bostonchefs/logging/
middleware.py", line 32, in process_response
self.activity.set_request_time()

AttributeError: 'Activity' object has no attribute 'activity'


I'm pretty sure htis is just evidence that my middleware isn't playing
nice with CommonMiddleware, but I'm not sure the best way to go about
solving it. Is it just an issue of which is loaded first? I'd assume
that CommonMiddleware should be loaded first so that it can handle the
slash problem before the request even makes it to my middleware, but
that appears to not be the case.

This is what my MIDDLEWARE_CLASSES looks like:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.doc.XViewMiddleware',
'django.middleware.http.SetRemoteAddrFromForwardedFor',
'bostonchefs.logging.middleware.Activity',
)

Anyone have any ideas?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Middleware problem

[Josh]

I created a custom middleware for logging requests based on this blog
post: http://whijo.net/blog/brad/2007/07/19/statistics-logging-django.html

It's mostly working fine except for one thing. It causes problems when
a URL without a trailing / is requested. In that case it gives me the
following error:
  File "/home/bostonchefs/webapps/django/bostonchefs/logging/
middleware.py", line 32, in process_response
self.activity.set_request_time()

AttributeError: 'Activity' object has no attribute 'activity'

I'm pretty sure htis is just evidence that my middleware isn't playing
nice with CommonMiddleware, but I'm not sure the best way to go about
solving it. Is it just an issue of which is loaded first? I'd assume
that CommonMiddleware should be loaded first so that it can handle the
slash problem before the request even makes it to my middleware, but
that appears to not be the case.

This is what my MIDDLEWARE_CLASSES looks like:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.doc.XViewMiddleware',
'django.middleware.http.SetRemoteAddrFromForwardedFor',
'myproject.logging.middleware.Activity',
)

Anyone have any ideas?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

middleware irritation

[Constantin Christmann]

Hello,

lately I installed a middleware to track user activity on my website 
(mainly code from this blog post 
http://whijo.net/blog/brad/2007/07/19/statistics-logging-django.html)

I use the following middleware classes:
MIDDLEWARE_CLASSES = (
 'django.middleware.common.CommonMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware',
 'django.middleware.http.SetRemoteAddrFromForwardedFor',
 'tucent.analytics.middleware.Activity',
 'django.middleware.transaction.TransactionMiddleware',
)

The problem is that if I enter urls without trailing slash I get an 
error in my Activity class inside the process_response function.
The cause for this error is that process_response gets called before the 
process_request has been called and a required variable is not instanciated.

How can that be? When CommonMiddleware is redirecting the request 
without the trailing slash this should never reach my Activity 
middleware? Or am I missing something here?

Thanks,
Constantin

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Middleware Ordering

[kevinski]

I count 12 available middleware classes at 
http://docs.djangoproject.com/en/dev/ref/middleware/,
however I can not find a complete listing of the best order to place
them. I have read tips here and there about what to do with some of
them, but can someone please provide me with the definitive list for
positioning them if for some reason I decided I needed to use them
all?

Thanks,
Kevin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Middleware Ordering

[kevinski]

I count 12 available middleware classes at 
http://docs.djangoproject.com/en/dev/ref/middleware/,
however I can not find a complete listing of the best order to place
them. I have read tips here and there about what to do with some of
them, but can someone please provide me with the definitive list for
positioning them if for some reason I decided I needed to use them
all?

Thanks,
Kevin
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Debug middleware

[Kless]

How to debug a middleware? I would print any variables for a
middleware that I'm building

Is there any way to make it?

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

middleware question

[Tim Arnold]

Hi, I want to serve some raw xml files, but add a stylesheet to the
response so the user can view it better.

The raw xml begins like this:
 http://docbook.org/ns/docbook"; version="5.0">
etc.
 

 I want to create some middleware to serve them like this:
 
 
 http://docbook.org/ns/docbook"; version="5.0">
etc.
 

 I've got this as a starting point but I have my doubts about it. Even
if it works, my guess is it will put an xml-stylesheet as an element,
not as a processing instruction.
 -
 css = '/media/css/XSL/driver.css'

 class XMLMiddleware(object):
 def process_response(self, request, response):
 if request.path.endswith('.xml'):
 response['xml-stylesheet'] = css
 return response


 I haven't wired anything up to test yet; I thought I'd ask if this is
the right way to do it before going much further.
 thanks,
 --Tim

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

Re: middleware

[Calvin Spealman]

You should use Django Debug Toolbar. It can handle this sort of thing,
and many other things, for you.

On Thu, Jul 14, 2011 at 1:34 AM, NISA BALAKRISHNAN
 wrote:
> how to write a middleware that that stores all database requests.
> How can i store all database requests?
>
> pls help
>
> --
> You received this message because you are subscribed to the Google Groups 
> "Django users" group.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to 
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/django-users?hl=en.
>
>



-- 
Read my blog! I depend on your acceptance of my opinion! I am interesting!
http://techblog.ironfroggy.com/
Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy

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

Middleware order

[David]

Hi

This is how my middleware is currently ordered:

'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.gzip.GZipMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.transaction.TransactionMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware',
'debug_toolbar.middleware.DebugToolbarMiddleware',
'reversion.middleware.RevisionMiddleware',

My problem for example is this. I have a form editting an object. If I 
submit/save the object it is saved successfully, however when redirecting 
back to that edit object form the old data persists. I suspect this is down 
to the order of my middleware.

Have I gone wrong somewhere?

Thank you

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-users/-/jkFCQ_SsvtoJ.
To post to this group, send email to django-users@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

SOPA middleware

[Gabriel Gunderson]

Django peeps,

I know it's a little late to make much use of the code, but I thought
I'd mention it anyway...

See the SOPA middleware in action (will auto-heal tonight): http://izeni.com/

Download it: http://dl.dropbox.com/u/47654226/sopa_protest.tar.gz

It was quickly hacked together and no doubt needs some love, but for
today, it got the job done. Let's hope we're not given another chance
to revisit the code :)


Best,
Gabe

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

Re: middleware

[Shawn Milochik]

In your middleware you'll have access to the request object, so you can
easily check the URL, user, etc.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: middleware

[Hristo Deshev]

> > Does anyone know if is possible execute a middleware only to a specific 
> > application or url?

On 05/09/2013 04:56 PM, Shawn Milochik wrote:
> In your middleware you'll have access to the request object, so you can
> easily check the URL, user, etc.

I'd consider a solution based on view decorators too:

https://docs.djangoproject.com/en/dev/topics/http/decorators/

Hristo



signature.asc
Description: OpenPGP digital signature

Re: middleware

[Bill Freeman]

The specific URL part has been answered.

I'm presuming that you want something automatic for a third party app that
you don't want to modify.

In process_view you have access to the view function.  You should be able
to introspect that to figure out whether it is supplied by the target app
or not.  This is too late to control anything in process_request, but,
since you can decorate the request in process_view if you find that it is
from your target app, all the other proces_xxx methods can benefit from
your determination.

Bill


On Fri, May 10, 2013 at 6:40 AM, Hristo Deshev  wrote:

> > > Does anyone know if is possible execute a middleware only to a
> specific application or url?
>
> On 05/09/2013 04:56 PM, Shawn Milochik wrote:
> > In your middleware you'll have access to the request object, so you can
> > easily check the URL, user, etc.
>
> I'd consider a solution based on view decorators too:
>
> https://docs.djangoproject.com/en/dev/topics/http/decorators/
>
> Hristo
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

middleware question

[Marcin Szamotulski]

Dear Django Gurus,

I have a simple question about middleware.  I have a middleware object
which looks like this:


class MyMiddleware(object):

def process_view(...):

...
self.data = some data
...


def process_template_response(...):

data = self.data
del self.data

...

It works fine when I test it myself, but the question is what is a life
cycle of middleware objects.  Will this work when there is a big
traffic?   So the question is if middleware objects are instantiated for
every request and then garbage collected?


Best regards,
Marcin Szamotulski

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Middleware + Transactions

[Thomas Güttler]

Dear Django developers,

we currently have the following issue when upgrading from Django 1.5 to Django 1.6: 
https://github.com/etianen/django-reversion/issues/268


As it seems, since Django 1.6, middlewares are not supposed to be executed within the same transaction as the view 
function is.


We would like to understand why that is the default behavior now and we are supposed to re-organize our code base to 
work with that changes.


What is the rationale behind middlewares not being executed within the same 
transaction as the view function?

Furthermore, decorating all view functions as suggested here 
http://django-reversion.readthedocs.org/en/latest/api.html#revisionmiddleware is quite not feasible for large projects. 
Especially given that reversion is not the only middleware that needs to be executed within the same transaction as the 
view function. It would basically mean that each view function needs to be decorated potentially n times.



We understand that transactions might effect performance, thus lesser transactions being in a transaction means faster 
execution. However, shouldn't there be the possibility to include distinct middlewares into the view transaction?


Regards,
  Thomas Güttler

--
Thomas Güttler
http://thomas-guettler.de/

--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/54CB8E78.7060604%40tbz-pariv.de.
For more options, visit https://groups.google.com/d/optout.

Email Middleware

[Stefano Probst]

Hello,
i search for a universal way to modify the content of a mail before send 
it. Is there a middleware like system for mails?
Background: I want to program a system which encrypt outgoing mails via PGP.

Best regard
Stefano

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/6c987d84-2205-4e4d-a131-0d3cbf4fd923%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: middleware

[Mayank G]

Middleware allows you to process certain pre specified activities like,
Logging, User Authentication, Tokenization and filtration of data. Route
authentication, Access control list validations.
It provides flexibility to invoke appropriate middleware on different
routes.
These act as glue to provide extra functionality.
Certain tasks which need to be processed before of after serving request,
it must be included inside middleware

On Tue, Aug 25, 2015 at 4:44 PM, Pawanesh Gautam  wrote:

> why middleware is required ??
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/b160c03e-a9c2-42f9-a95e-52fbace330c9%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/b160c03e-a9c2-42f9-a95e-52fbace330c9%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CA%2B_AzAQp9CBfbaS6AZxE-aEqoA48%2BbN%3D7pyuHS889%2BLBEaYsWw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

middleware question

[Chris]

Is there a way to grab content_type and object_id in a middleware
processor? Example if I went to my articles section:
http://www.xyz.com/articles// could I some how get the
content_type and the object_id from the request context that is passed
in? I want to be able to perform a middleware task but need to know
what model and object that I am dealing with.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

middleware introspection

[Robin Becker]

A colleague is writing a response middleware which hijacks the normal view 
under 
certain circumstances. Diagramatically


V0  -->M(0)--> V1  is the normal case view V0 goes directly  to V1 ie the 
middleware M does nothing.

when the hijack is to take place

V0 -->M(1)-->V2-->M(0)-->V1

Now my question

can the middleware determine the template used by V0 so that it can be used 
automatically to generate V2?
-- 
Robin Becker

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Middleware sessions

[kbochert]

After a long absence, I tried my installation of the tutorial and got:

Error importing middleware django.middleware.sessions

My settings.py  has:
MIDDLEWARE _CLASSES = {


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Middleware sessions

[kbochert]

After a long absence, I tried my installation of the tutorial and got:

Error importing middleware django.middleware.sessions

My settings.py  has:
MIDDLEWARE _CLASSES = {
   "django.middleware.sessions.SessionMiddleware",
   ...

I change this to :
MIDDLEWARE _CLASSES = {
"django.contrib.sessions.middleware.SessionMiddleware",
...

And all is fine.

Should 'sessions' be in middleware or contrib ??

Karl


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Redirect middleware

[plungerman]

greetings,

i am attempting to do a simple redirect using django's redirect
middleware.  everything works fine if you want to redirect from one
distinct URI to another, for example,

/big/ ---> http://www.example.com/labowski/

however, if you want to redirect to a child page in terms of the URI
structure, it does not seem to work for me.  for example:

/about/ ---> http://www.example.com/about/broscoen/

what we have here, is an about page that is not finished, so we want
folks who request /about/ to go to a subpage but instead you see the /
about/ page.

we are using apache with mod_python, so i attempted to make it work
using apaches Redirect manoeuvre.  this was even more fatal, as the
Redirect directive will redirect anything that comes in with the /
about/ root to /about/broscoen/ , which went into a loop and so we
had /about/broscoen/broscoen/broscoen/broscoen/ etc until apache gave
up on the request.

so i was thinking that perhaps django does not permit this type of
redirect.  can anyone confirm that?  has anyone else had the same
problem?

huge thanks in advance.

yours,

steve


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Maintainance Middleware

[Christian M Hoeppner]

Hi there!

How would one handle the following tasks in a middleware?

If a settings called "MAINTENANCE" is true, check if the user is logged in. If 
he is, let him view the requested page normally. If not, redirect to 
maintenance page.

If setting is false, show page normally despite user logged in or not.

It's a way to show unauthorised users an "under construction" page while the 
maintenance settings is set to true.

Can anyone give me some advice, or perhaps point me to someone who already 
solved this task?

Thanks,
Chris Hoeppner
www.pixware.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

middleware needed

[lawgon]

I set up a django installation, but when i tried to run the admin
thingie, i get this message:
Traceback (most recent call last):

  File
"/usr/local/lib/python2.4/site-packages/django/core/handlers/base.py",
line 60, in get_response
response = middleware_method(request, callback, param_dict)

  File
"/usr/local/lib/python2.4/site-packages/django/middleware/admin.py",
line 41, in process_view
assert hasattr(request, 'session'), "The admin requires session
middleware to be installed. Edit your MIDDLEWARE_CLASSES setting to
insert 'django.middleware.sessions.SessionMiddleware' before %r." %
self.__class__.__name__

AssertionError: The admin requires session middleware to be installed.
Edit your MIDDLEWARE_CLASSES setting to insert
'django.middleware.sessions.SessionMiddleware' before
'AdminUserRequired'.

i edited admin.py in the middleware directory and added this:

MIDDLEWARE_CLASSES = (
"django.middleware.sessions.SessionMiddleware",
"django.middleware.admin.AdminUserRequired",
"django.middleware.common.CommonMiddleware",
)

before the lines AdminUserRequired. But there is no change - same error
is coming up. Any clues?

SSL Middleware

[Antonio Cavedoni]

Hello everyone,

yesterday I came up with a Django middleware that has the potential  
to be actually useful!

I called it SSL Middleware, and what it does is take a tuple of paths  
(HTTPS_PATHS in the settings file) and redirect all the http://  
requests for paths starting with these values to their https://  
counterpart.

In reverse, if an https:// request is made on a path that does *not*  
start with one of the values in the tuple, that will be redirected to  
its http:// version.

The code is here:

http://unicoders.org/code/django/trunk/middleware/sslmiddleware.py

Cheers!
-- 
Antonio



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

middleware or view ?

[PonasNiekas]

Hi,

I'm about to write an app, which is going to do long running (~1 to
~60 minutes) calculations (meanwhile, the user who triggered the
calculation will get message like "calculation in progress" or smth).

I'm wondering what is the right place or best practice to do such
calculations, custom middleware or view ?

Thanks,
PonasNiekas

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

creating django middleware

[ershadul]

Dear all,
please consider the following code-block:

class SQLAlchemySessionMiddleware(object):
"""
This class instantiates a sqlalchemy session and destroys
"""
def process_request(self, request):
request.db_session = session()
return None

def process_response(self, request, response):
session_destroy(request.db_session)
return response

Consider that session() is method that returns a new object sqlalchemy
session.
I want to inject it before view is processed and destroy it upon
exiting the view.

I have added the path of this middleware class before XView
middleware in settings.py.
But i got a error that
request has not attribute 'db_session' ( process_response function)
How can i do it?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Order of Middleware

[Peter]

When I run django admin and do startproject I get a settings file that
has:

MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
)

In the global_settings.py file there is:

# List of middleware classes to use.  Order is important; in the
request phase,
# this middleware classes will be applied in the order given, and in
the
# response phase the middleware will be applied in reverse order.

MIDDLEWARE_CLASSES = (
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
# 'django.middleware.http.ConditionalGetMiddleware',
# 'django.middleware.gzip.GZipMiddleware',
'django.middleware.common.CommonMiddleware',
)

Order is declared to be important so which is the correct order?

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

middleware import errors

[Vladimir Kirillov]

using django-1.0.2 with apache-1.3 (OpenBSD), python-2.4, fastcgi and
py-flup-1.0 from yesterday's mercurial tip throws these logs into
error-log and 500 to any requests:
apache error logs:
 Traceback (most recent call last):
   File "../lib/flup/server/fcgi_base.py", line 558, in run
   File "../lib/flup/server/fcgi_base.py", line 1116, in handler
   File "../lib/django/core/handlers/wsgi.py", line 228, in __call__
   File "../lib/django/core/handlers/base.py", line 40, in
load_middleware
 ImproperlyConfigured: Error importing middleware
django.middleware.common: "No module named common"

(sometimes can be caused on other modules)

middleware list:
MIDDLEWARE_CLASSES = (
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.doc.XViewMiddleware',
)

developer server works ok.
any suggestions?

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

Caching middleware struggle

[pielgrzym]

Hi there,

I'm struggling to make caching middleware work with i18n middleware,
with no success though (a user can't change the language - since he
gets the first cached language site...). Those nifty decorators for
vary headers  don't help too. Same goes for the middleware itself -
I've tried to use this snippet:
http://www.djangosnippets.org/snippets/443/

It makes the i18n finally work with cache but then middleware ignores
auth and doesn't detect that a user has logged out or in.

I've tried numerous variations of middleware order, here is the latest
that works with the snippet:
MIDDLEWARE_CLASSES = (
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
#'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.locale.LocaleMiddleware',
'clubtube.cachewrapper.VaryOnLangCacheMiddleware',
'django.middleware.common.CommonMiddleware',
#'django.middleware.cache.FetchFromCacheMiddleware',
)

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

per-application middleware

[Philip Zeyliger]

Hi,

I have a project made up of several applications, and one of those
applications needs some specific middleware, whereas the others don't.  Is
there a way to enable middleware per-application?

Thanks,

-- Philip

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

middleware cache problem

[Norman]

Hi all,

I cache my view that show a list of stories, but I have also small
voting button (like digg). Voting is done be middleware class (it
reads user IP), so I can ask for view with list of stories and tell
that this list shall be cached and I have to ask middleware for vote
results.

Unfortunaltely when cache is ON my middleware voting class isn't asked
for voting results.

What can I do to mix cache from view and live results from my
middleware voting class?

regards, Normanek
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: middleware irritation

[Constantin Christmann]

Hello,

I solved it myself...
After some logging I found out that the Acitivity's process_request is 
indeed never reached (that I knew already :) but when CommonMiddleware 
does his append slash-stuff the full(!) process_response chain is 
processed - which means also the Acitvity's process_response.

Constantin Christmann schrieb:
> Hello,
> 
> lately I installed a middleware to track user activity on my website 
> (mainly code from this blog post 
> http://whijo.net/blog/brad/2007/07/19/statistics-logging-django.html)
> 
> I use the following middleware classes:
> MIDDLEWARE_CLASSES = (
>  'django.middleware.common.CommonMiddleware',
>  'django.contrib.sessions.middleware.SessionMiddleware',
>  'django.contrib.auth.middleware.AuthenticationMiddleware',
>  'django.middleware.http.SetRemoteAddrFromForwardedFor',
>  'tucent.analytics.middleware.Activity',
>  'django.middleware.transaction.TransactionMiddleware',
> )
> 
> The problem is that if I enter urls without trailing slash I get an 
> error in my Activity class inside the process_response function.
> The cause for this error is that process_response gets called before the 
> process_request has been called and a required variable is not instanciated.
> 
> How can that be? When CommonMiddleware is redirecting the request 
> without the trailing slash this should never reach my Activity 
> middleware? Or am I missing something here?
> 
> Thanks,
> Constantin
> 
> > 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Middleware problem

[Josh]

Turns out the problem was my own fault. My process_response() wasn't
handling exceptions properly. I changed it from this:

def process_response(self, request, response):
self.activity.set_request_time()
return response

to this:

def process_response(self, request, response):
try:
self.activity.set_request_time()
except:
pass
return response

and that took care of it.

On May 28, 7:19 pm, Josh <[EMAIL PROTECTED]> wrote:
> I created a custom middleware for logging requests based on this blog
> post:http://whijo.net/blog/brad/2007/07/19/statistics-logging-django.html
>
> It's mostly working fine except for one thing. It causes problems when
> a URL without a trailing / is requested. In that case it gives me the
> following error:
>   File "/home/bostonchefs/webapps/django/bostonchefs/logging/
> middleware.py", line 32, in process_response
>     self.activity.set_request_time()
>
> AttributeError: 'Activity' object has no attribute 'activity'
>
> I'm pretty sure htis is just evidence that my middleware isn't playing
> nice with CommonMiddleware, but I'm not sure the best way to go about
> solving it. Is it just an issue of which is loaded first? I'd assume
> that CommonMiddleware should be loaded first so that it can handle the
> slash problem before the request even makes it to my middleware, but
> that appears to not be the case.
>
> This is what my MIDDLEWARE_CLASSES looks like:
> MIDDLEWARE_CLASSES = (
>     'django.middleware.common.CommonMiddleware',
>     'django.contrib.sessions.middleware.SessionMiddleware',
>     'django.contrib.auth.middleware.AuthenticationMiddleware',
>     'django.middleware.doc.XViewMiddleware',
>     'django.middleware.http.SetRemoteAddrFromForwardedFor',
>     'myproject.logging.middleware.Activity',
> )
>
> Anyone have any ideas?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Per app middleware?

[Gabriel Rossetti]

Hello everyone,

I have a project that has two apps that use the same models (I moved it 
out of the apps, up to the project's root). I was wondering if it is 
possible to have global middleware (that they both need) and per app 
middleware (sspecific to each app). I don't want one app's middleware to 
intercept and process the other app's stuff, does anyone know how to do 
this?

Thank you,
Gabriel

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

Re: Debug middleware

[Malcolm Tredinnick]

On Sat, 2009-05-02 at 04:11 -0700, Kless wrote:
> How to debug a middleware? I would print any variables for a
> middleware that I'm building
> 
> Is there any way to make it?

In any sensible web server setup, printing to sys.stderr will send the
output the server's error log. With Django's development server (the
"runserver") command, it will send the output to the console that you
started the dev server from. So use

print >> sys.stderr, ""

to your heart's content.

Regards,
Malcolm



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

Re: Debug middleware

[George Song]

On 5/2/2009 9:53 AM, Malcolm Tredinnick wrote:
> On Sat, 2009-05-02 at 04:11 -0700, Kless wrote:
>> How to debug a middleware? I would print any variables for a
>> middleware that I'm building
>>
>> Is there any way to make it?
> 
> In any sensible web server setup, printing to sys.stderr will send the
> output the server's error log. With Django's development server (the
> "runserver") command, it will send the output to the console that you
> started the dev server from. So use
> 
> print >> sys.stderr, ""
> 
> to your heart's content.

Or you can always use `pdb` if you're running the development server.

-- 
George

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

Middleware stored locally

[When ideas fail]

If i have a lib folder in my app what is the correct way to reference
it in settings.py?

I've tried this

MIDDLEWARE_CLASSES = (
'myapp.lib.django_authopenid.middleware.OpenIDMiddleware'
   # and
  'myapp.django_authopenid.middleware.OpenIDMiddleware'
)

the file its in is

\Apache2.2\myapp\lib\django_authopenid

but I get a 500 Internal Server and the error log tells me the
following:

[Thu Oct 15 00:56:39 2009] [error] [client 127.0.0.1] raise
exceptions.ImproperlyConfigured, 'Error importing middleware %s: "%s"'
% (mw_module, e)
[Thu Oct 15 00:56:39 2009] [error] [client 127.0.0.1]
ImproperlyConfigured: Error importing middleware
abeona.django_authopenid.middleware: "No module named
django_authopenid.middleware"

I'd appreciate any help

Thanks

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

order of middleware

[Alessandro Ronchi]

Is this middleware classes correctly ordered for performance?
thanks in advance,

MIDDLEWARE_CLASSES = (


"django.middleware.common.CommonMiddleware",
"django.contrib.sessions.middleware.SessionMiddleware",
"django.middleware.locale.LocaleMiddleware",
"django.contrib.auth.middleware.AuthenticationMiddleware",
"django.middleware.doc.XViewMiddleware",
'django.middleware.gzip.GZipMiddleware',
'django.middleware.http.ConditionalGetMiddleware',
'pagination.middleware.PaginationMiddleware',
"django.contrib.flatpages.middleware.FlatpageFallbackMiddleware",
'django.contrib.redirects.middleware.RedirectFallbackMiddleware',


-- 
Alessandro Ronchi
http://www.soasi.com

Hobby & Giochi
http://hobbygiochi.com
http://www.facebook.com/hobbygiochi

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

Middleware for models

[pbzRPA]

Hi,

I don't actually have a problem but rather a need for a suggestion. I
am building a web application and in order to demo the site on one
database I have a need to secure the data for each user. I have a
field in each model that is a foreign key to a unique field on the
User model. The tricky part is that it's becoming a lot of maintenance
to check in each view if the record was created by the user or not. I
wrote a normal middleware that adds the users unique site to the
request. This helps with having the user site in each view but I was
wondering how I could get the user site into a model so that each time
a user calls a model or saves a model it validates that it was created
by that user.   Ideally I would like to get the users site into a
ModelManager and limit the queryset there and have the users site
available in the save method of a model. I do not want to add the
users site to the session as it's easy to manipulate a session
variable.

Is there any form of middleware for models so that you can pass the
request object to it?

Any advice will be highly appreciated.

Regards

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

Re: middleware question

[Peter Landry]

That will add a header to the http response, not an element to the text of
the xml output. There may be an easier way to do what you want with a
middleware, but the only thing I can think of is to basically prepend your
desired xml header to the response text and create a new HttpResponse with
that text.

Hope that helps,
Peter

On 4/20/10 2:57 PM, "Tim Arnold"  wrote:

> Hi, I want to serve some raw xml files, but add a stylesheet to the
> response so the user can view it better.
> 
> The raw xml begins like this:
>  http://docbook.org/ns/docbook"; version="5.0">
> etc.
>  
> 
>  I want to create some middleware to serve them like this:
>  
>  
>  http://docbook.org/ns/docbook"; version="5.0">
> etc.
>  
> 
>  I've got this as a starting point but I have my doubts about it. Even
> if it works, my guess is it will put an xml-stylesheet as an element,
> not as a processing instruction.
>  -
>  css = '/media/css/XSL/driver.css'
> 
>  class XMLMiddleware(object):
>  def process_response(self, request, response):
>  if request.path.endswith('.xml'):
>  response['xml-stylesheet'] = css
>  return response
> 
> 
>  I haven't wired anything up to test yet; I thought I'd ask if this is
> the right way to do it before going much further.
>  thanks,
>  --Tim

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

Re: Middleware order

[Furbee]

I don't know, but the revision middleware smells like it could be the
culprit. It is the last module in processing the request, and the first one
processing the response back up the chain. Maybe it is returning the old
data. Just a stab in the dark.

Furbee

On Tue, May 15, 2012 at 8:23 AM, David  wrote:

> Hi
>
> This is how my middleware is currently ordered:
>
> 'django.middleware.cache.UpdateCacheMiddleware',
> 'django.middleware.gzip.GZipMiddleware',
> 'django.contrib.sessions.middleware.SessionMiddleware',
> 'django.middleware.common.CommonMiddleware',
> 'django.middleware.csrf.CsrfViewMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> 'django.contrib.messages.middleware.MessageMiddleware',
> 'django.middleware.transaction.TransactionMiddleware',
> 'django.middleware.clickjacking.XFrameOptionsMiddleware',
> 'django.middleware.cache.FetchFromCacheMiddleware',
> 'debug_toolbar.middleware.DebugToolbarMiddleware',
> 'reversion.middleware.RevisionMiddleware',
>
> My problem for example is this. I have a form editting an object. If I
> submit/save the object it is saved successfully, however when redirecting
> back to that edit object form the old data persists. I suspect this is down
> to the order of my middleware.
>
> Have I gone wrong somewhere?
>
> Thank you
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-users/-/jkFCQ_SsvtoJ.
> To post to this group, send email to django-users@googlegroups.com.
> To unsubscribe from this group, send email to
> django-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-users?hl=en.
>

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

Login Required Middleware

[Blaxton]

Hi

I am trying to use login required middleware in a project
and followed every step mentioned on following url ,
but its just not working.

http://djangosnippets.org/snippets/1179/

placed the above middleware in myproject/middleware.py

added following lines to settings.py
LOGIN_URL = '/'
MIDDLEWARE_CLASSES = (

'myproject.middleware.LoginRequiredMiddleware'
)

django.core.context_processors.auth is changed to
django.contrib.auth.context_processors.auth

and it is in global_settings.py.

but still it wont forward the anonymouse users to login page which is '/'

Thanks

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

problem with middleware

[jenia ivlev]

Hello:

I have defined a middleware class. and i have added it to the
middleware_classes attribute in setting. When a request comes in, the
middleware class gets created (the debugger catches the code when the
breakpoint is on the class CommonFiilter(): line)

Now i expect the function  def process_template_response(self,
request, response): to get called. I have debug point on the inside of
the function and the debugger never traps the execution. The debugger,
though, traps the execution at the line where the function name and
parameters are defined.
This is the class:

class CommonFilter():#< debugger breaks here
def process_template_response(self, request, response): #<---
debugger breaks here
if response.template_name=='store/index2.html': #<--- NOT HERE
(or after this line)
catnames=getCategories()
 
response.context_data.update({'catnames':catnames,'user':request.GET.get(key='user',default=None)})
return response

Also tried this:

class CommonFilter():#< debugger breaks here
def process_template_response(self, request, response):#<
debugger breaks here
if response.template_name=='store/index2.html':#<--- NOT HERE
(or after here)
catnames=getCategories()
response.context_data['catnames']=catnames
 
response.context_data['user']=request.GET.get(key='user',default=None)
return response

Just in case, this is the setting MIDDLEWWARE_CLASSES variable:

MIDDLEWARE_CLASSES = (
  'store.models.CommonFilter',
'django.middleware.csrf.CsrfViewMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
)

store is an app in this project and ofcourse CommonFilter is defined
in models.py.

Why is the function process_template_response function not being
executed?

Thanks for your time and kind concern.

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

Re: middleware question

[Marcin Szamotulski]

I did some test myself and the best thing what I can do is to attach
data to the request since its live cycle is what I actually need.

Best regards,
Marcin

On 14:20 Sat 25 May , Marcin Szamotulski wrote:
> Dear Django Gurus,
> 
> I have a simple question about middleware.  I have a middleware object
> which looks like this:
> 
> 
> class MyMiddleware(object):
> 
> def process_view(...):
>   
>   ...
>   self.data = some data
>   ...
> 
> 
> def process_template_response(...):
> 
>   data = self.data
>   del self.data
> 
>   ...
> 
> It works fine when I test it myself, but the question is what is a life
> cycle of middleware objects.  Will this work when there is a big
> traffic?   So the question is if middleware objects are instantiated for
> every request and then garbage collected?
> 
> 
> Best regards,
> Marcin Szamotulski

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Email Middleware

[Stefano Probst]

I implement the software now as a custom email backend 
.
 
My backend manipulate the content of the message and act as wrapper for the 
real mail backend.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/f3de37c4-bcd6-401e-88c5-19a7216d3f73%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

New-style middleware

[Torsten Bronger]

Hallöchen!

Considering the following old-style middleware class:

class ExceptionsMiddleware:
def process_exception(self, request, exception):
...

I convert this to new-style middleware by inserting two methods:

class ExceptionsMiddleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
return self.get_response(request)
def process_exception(self, request, exception):
...

Is this really correct?  Actually, the old way looks more concise to
me.  In particular, is there a reason why Django does not provide a
non-deprecated base class for middleware like:

class Middleware:
def __init__(self, get_response):
self.get_response = get_response
def __call__(self, request):
return self.get_response(request)

(I know MiddlewareMixin but it is deprecated.)

Tschö,
Torsten.

-- 
Torsten Bronger

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/87oa17kxsd.fsf%40physik.rwth-aachen.de.
For more options, visit https://groups.google.com/d/optout.

Cache middleware problem

[T Kwn]

I have a list view where I can add or delete objects. I found that if the 
cache middleware is included:

'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware'

The page doesn't operate properly. Basically deleted objects don't always 
disappear.
Added objects didn't display etc. I verified objects are created or deleted by 
viewing the db file.

Finally I deleted the cache middelware and now the page operates properly. 

So when I finally go into production will I have a problem because there's no 
caching? Or 
if I want to enable caching, how do I prevent this problem again? It appears 
the cache
middleware isn't operating properly but I can't see how it wouldn't have been 
fixed by now...

I'm running python 2.7 and django 1.6.2




-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/c356fe31-8c94-4744-8040-e66c5524ead4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: middleware question

[Chris]

Can anyone help me with this? It looks like I need to pass in a
django_content_type= to the request context
before it gets passed to the middleware for further processing. Any
thoughts?

On Apr 2, 3:37 pm, Chris <[EMAIL PROTECTED]> wrote:
> Is there a way to grab content_type and object_id in a middleware
> processor? Example if I went to my articles 
> section:http://www.xyz.com/articles// could I some how get the
> content_type and the object_id from the request context that is passed
> in? I want to be able to perform a middleware task but need to know
> what model and object that I am dealing with.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: middleware question

[Russell Keith-Magee]

On 4/3/08, Chris <[EMAIL PROTECTED]> wrote:
>
>  Can anyone help me with this? It looks like I need to pass in a
>  django_content_type= to the request context
>  before it gets passed to the middleware for further processing. Any
>  thoughts?

Yes. I think you need to wait more than 30 minutes before you expect a
response. :-)

The request object isn't going to be associated with any Django models
by default. I suspect what you will need to do is use the get_app()
and get_model() functions in django.db.models; these functions access
the Django application cache, and allow you to retrieve a model/app
etc by name. Extract the name of the model of interest from the
request, and obtain the corresponding model using the cache functions.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

browser detection middleware

[omat]

Hi all,

Is it a good idea to use a middleware class to detect the browser
client looking at the HTTP_USER_AGENT so as to serve presentation
logic accordingly, for mobile devices or older browsers, etc...?

I know this is mostly done by 

Middleware tests location

[Eugene Morozov]

Hello,
I have a custom middleware class that would be used project-wide. I've
put it in the 'middleware' subdirectory of my project because it
doesn't really belong to any app.

The question is where to put tests for such code that exists outside
of any application? Django default test runner only runs tests for
installed applications.

Should I write custom test runner, or create a fake application that
will consolidate tests for all project libraries?
Eugene


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

html validator middleware

[Brian St. Pierre]

I recently hacked together a small middleware that validates all
outgoing html and if it encounters a validation error, throws a 500
status code and error page with the validation error message(s) and
html source.

Similar in aim to Luke Plant's Validator App (http://lukeplant.me.uk/
resources/djangovalidator/), but lighter weight.

Requires python 2.4 (for the subprocess module).
Requires the offline "validate" utility for HTML validation from
HTMLHelp.com, or its equivalent.

Available here: http://bstpierre.org/Projects/HtmlValidatorMiddleware/

Comments & questions welcome.

-Brian St. Pierre
[EMAIL PROTECTED]


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

middleware or context_processors

[james_027]

Hi all,

As I am trying to extend the django user model not using the
auth_profile

I have model like this

class Profile(models.Model):
"""KSK Employee accounts to use this application"""

user = models.ForeignKey(User, unique=True)
department = models.CharField(maxlength=3,
choices=DEPARTMENT_LIST)
level = models.CharField(maxlength=3, choices=LEVEL_LIST)



class Admin:
pass

def _get_username(self):
return self.user.username

username = property(fget=_get_username)

In order to make use of the profile model as easy as the django user
model

I can make a middleware like this

from ksk.main.models import Profile

class ProfileMiddleware(object):
"""Use to synchronize django user and ksk profile"""

def process_request(self, request):
if request.user.is_authenticated():
request.profile = Profile.objects.get(user = request.user)
else:
request.profile = None

and with context_processors like this

def profile(request):
return {'profile': request.profile}


or just use only context_processors like this

from ksk.main.models import Profile
def profile(request):
if request.user.is_authenticated():
profile = Profile.objects.get(user = request.user)
else:
profile = None
return {
 'profile': profile,

}

both of them works, but I don't have any idea which is better in terms
of design? security? performance?

Thanks
james


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: middleware introspection

[Jeremy Dunck]

On 10/5/07, Robin Becker <[EMAIL PROTECTED]> wrote:
> can the middleware determine the template used by V0 so that it can be used
> automatically to generate V2?

Yes.  Have a look at django.test.utils.instrumented_test_render and
.setup_test_environment.
You'll see a way to monkeypatch Template.render to make a signal fire
when templates are rendered.

You can have your middleware initialize a list on the request object
before V0 is called (process_request), add templates to the list when
the signal is fired, then do something based on which templates were
used (process_response).

If you find that signal useful, it may be that such a real-world
requirement would drive django.test.signals.template_rendered to be
changed to always fire rather than just when monkeypatched by
django.test.  :)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Middleware sessions

[Joseph Heck]

As of the "magic removal" (the bits just prior to the 0.95 release),
sessions was moved into contrib.

-joe

On 2/2/07, kbochert <[EMAIL PROTECTED]> wrote:
>
>
> After a long absence, I tried my installation of the tutorial and got:
>
> Error importing middleware django.middleware.sessions
>
> My settings.py  has:
> MIDDLEWARE _CLASSES = {
>"django.middleware.sessions.SessionMiddleware",
>...
>
> I change this to :
> MIDDLEWARE _CLASSES = {
> "django.contrib.sessions.middleware.SessionMiddleware",
> ...
>
> And all is fine.
>
> Should 'sessions' be in middleware or contrib ??
>
> Karl
>
>
> >
>

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Transaction middleware + Filesystem

[Paul Collier]

Hello!

Is there any way to tie file-system operations (or other non-database
operations) to the transaction code? If the operation is found right
in the view function it's simply a matter of moving the file operation
to the end of the function and doing a rollback if it fails. However,
if it happens inside several layers of function calls this becomes
difficult.

Is there some sort of common Django or Python idiom for this sort of
thing, an easy way to add hooks to the transaction middleware, or
should I just stop being so paranoid about consistency? ;)

Thanks!
- Paul


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

SQL Debug middleware

[Jesse Lovelace]

Hey all,

I made this the other day to help me track all the sql statements my
pages were doing.  I wanted something unobtrusive (i.e. middleware)
and simple.  Hope you like:

from django.db import connection
import re, pprint

body_end = re.compile('', re.IGNORECASE)

class DebugMiddleware(object):

def process_response(self, request, response):
if body_end.search(response.content) is not None:
db_info = pprint.pformat(connection.queries)
total = 0.0
for con in connection.queries:
total += float(con['time'])
response.content = body_end.sub('%s\nTotal: 
%f' %
(db_info,total), response.content)
return response

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Redirect middleware

[Michael K]

On Apr 23, 10:13 am, plungerman <[EMAIL PROTECTED]> wrote:
> greetings,
>
> i am attempting to do a simple redirect using django's redirect
> middleware.  everything works fine if you want to redirect from one
> distinct URI to another, for example,
>
> /big/ --->http://www.example.com/labowski/
>
> however, if you want to redirect to a child page in terms of the URI
> structure, it does not seem to work for me.  for example:
>
> /about/ --->http://www.example.com/about/broscoen/
>
> what we have here, is an about page that is not finished, so we want
> folks who request /about/ to go to a subpage but instead you see the /
> about/ page.

Steve,

I've had a similar problem before, unrelated to redirect middleware,
but related to urlconfs.   What do your urlconfs look like for the
about pages/sub-pages?

Michael


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Redirect middleware

[plungerman]

well, here's the thing.  for this application, we are using database
templates and a CMS system we created to manage content.  so basically
we have all of our urls in the urls.py file for things like a blog, a
portfolio manager, tags, authentication, etc listed first.  the last
item in the urls.py file is for the CMS pages, and grabs everything in
the URI with the following reg ex:

(r'^%s(?P[^?#]*)' % (root_url), 'apps.cms.views.render'),

in the render view we munge the URI from parent through child pages to
find the final slug that tells us what page to retrieve for viewing.
i suspect that something is going wrong in that department.  what do
you think?



On Apr 23, 5:06 pm, Michael K <[EMAIL PROTECTED]> wrote:
> On Apr 23, 10:13 am, plungerman <[EMAIL PROTECTED]> wrote:
>
>
>
> > greetings,
>
> > i am attempting to do a simpleredirectusing django'sredirect
> > middleware.  everything works fine if you want toredirectfrom one
> > distinct URI to another, for example,
>
> > /big/ --->http://www.example.com/labowski/
>
> > however, if you want toredirectto a child page in terms of the URI
> > structure, it does not seem to work for me.  for example:
>
> > /about/ --->http://www.example.com/about/broscoen/
>
> > what we have here, is an about page that is not finished, so we want
> > folks who request /about/ to go to a subpage but instead you see the /
> > about/ page.
>
> Steve,
>
> I've had a similar problem before, unrelated toredirectmiddleware,
> but related to urlconfs.   What do your urlconfs look like for the
> about pages/sub-pages?
>
> Michael


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Redirect middleware

[oggie rob]

>
> (r'^%s(?P[^?#]*)' % (root_url), 'apps.cms.views.render'),
>

Note that '?' is a special character, but more importantly your
expression probably matches both the initial request and the
redirected one. Check it out:
>>> r = re.compile('/about/(?P[^?#]*)')
>>> r.match('/about/?user1')
<_sre.SRE_Match object at 0x4d420>
>>> r.match('/about/mydir/user1/')
<_sre.SRE_Match object at 0x4d3a0>

You should escape the ? and perhaps sure up the expression by
eliminating slashes. e.g. the following *might* be okay, something
similar almost certainly will be.
>>> r = re.compile(r'/about/\?(?P[^\?#/]*)')
>>> r.match('/about/mydir/user1/')
>>> r.match('/about/?user1')
<_sre.SRE_Match object at 0x4d420>

 -rob


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Redirect middleware

[plungerman]

hi rob,

i think you are on to something there.  i should familiarise myself
more with reg ex, certainly one of my weaknesses.  basically what we
want to match on is anything from the root_uri ("/") to the end of the
path.  so about/mydir/user1/ would be passed to our view for
munging.

i kind of thought that the django redirect would happen first so when
a request comes in for /about/ the redirect would take it from there
and send a redirect to /about/mydir/ for example.  unfortunately, the
redirect is only invoked after all other options fail.  so we must
work around the django architecture for redirects.

thanks for your help.

yours,

steve


On Apr 23, 8:07 pm, oggie rob <[EMAIL PROTECTED]> wrote:
> > (r'^%s(?P[^?#]*)' % (root_url), 'apps.cms.views.render'),
>
> Note that '?' is a special character, but more importantly your
> expression probably matches both the initial request and the
> redirected one. Check it out:>>> r = re.compile('/about/(?P[^?#]*)')
> >>> r.match('/about/?user1')
>
> <_sre.SRE_Match object at 0x4d420 r.match('/about/mydir/user1/')
>
> <_sre.SRE_Match object at 0x4d3a0>
>
> You should escape the ? and perhaps sure up the expression by
> eliminating slashes. e.g. the following *might* be okay, something
> similar almost certainly will be.>>> r = 
> re.compile(r'/about/\?(?P[^\?#/]*)')
> >>> r.match('/about/mydir/user1/')
> >>> r.match('/about/?user1')
>
> <_sre.SRE_Match object at 0x4d420>
>
>  -rob


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Redirect middleware

[Laurie Harper]

oggie rob wrote:
>> (r'^%s(?P[^?#]*)' % (root_url), 'apps.cms.views.render'),
> Note that '?' is a special character, ...

Nope; it's special outside a character class ([...]), but in a character 
class ? has no special meaning.

L.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Redirect middleware

[oggie rob]

On Apr 26, 12:16 pm, Laurie Harper <[EMAIL PROTECTED]> wrote:
> oggie rob wrote:
> >> (r'^%s(?P[^?#]*)' % (root_url), 'apps.cms.views.render'),
> > Note that '?' is a special character, ...
>
> Nope; it's special outside a character class ([...]), but in a character
> class ? has no special meaning.
>
> L.

Didn't realize that, but it makes sense and is good to know!

 -rob


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Maintainance Middleware

[Jeremy Dunck]

On 5/15/07, Christian M Hoeppner <[EMAIL PROTECTED]> wrote:
>
> Hi there!
>
> How would one handle the following tasks in a middleware?

Put this somewhere in your app:
==
class MaintenanceMiddleware(object):
  def process_request(self, request):
from django.conf import settings
from django.http import HttpResponseRedirect

if settings.MAINTENANCE and not request.user.is_authenticated()
   return HttpResponseRedirect("/maintenance/")
return None

===

Then add that to your MIDDLEWARE_CLASSES list; make sure it's after
AuthenticationMiddleware so that request.user exists.

Request middleware short-circuits the request cycle if it returns a
HttpResponse instance.

More:
http://www.djangoproject.com/documentation/middleware/#process-request

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Maintainance Middleware

[[EMAIL PROTECTED]]

> Hi there!
> 
> How would one handle the following tasks in a middleware?
> 
> If a settings called "MAINTENANCE" is true, check if the user is logged in. 
> If 
> he is, let him view the requested page normally. If not, redirect to 
> maintenance page.
> 
> If setting is false, show page normally despite user logged in or not.
> 
> It's a way to show unauthorised users an "under construction" page while the 
> maintenance settings is set to true.
> 
> Can anyone give me some advice, or perhaps point me to someone who already 
> solved this task?
> 
Something like this (i didn't check if this code works):

from django.conf import settings
from django.http import HttpResponseRedirect

class MaintenanceMiddleware(object):
 def process_request(self, request):
 if settings.MAINTENANCE:
 if not request.user.is_authenticated():
 return HttpResponseRedirect('/maintenance/')
 return None

Put this middleware after AuthenticationMiddleware in the settings.py

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Maintainance Middleware

[Christian M Hoeppner]

> Something like this (i didn't check if this code works):
>
> from django.conf import settings
> from django.http import HttpResponseRedirect
>
> class MaintenanceMiddleware(object):
>  def process_request(self, request):
>  if settings.MAINTENANCE:
>  if not request.user.is_authenticated():
>  return HttpResponseRedirect('/maintenance/')
>  return None
>
> Put this middleware after AuthenticationMiddleware in the settings.py

Of course, this would work, but it also prevents users not logged in from 
logging in. Is there a way to check if the user is accessing the login view, 
in order to let him access his account and the site being under maintenance?

Thanks,
Chris Hoeppner
www.pixware.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Maintainance Middleware

[Jeremy Dunck]

On 5/15/07, Christian M Hoeppner <[EMAIL PROTECTED]> wrote:
...
> Of course, this would work, but it also prevents users not logged in from
> logging in. Is there a way to check if the user is accessing the login view,
> in order to let him access his account and the site being under maintenance?

You're more likely to get working code if all the requirements are stated.  :)

Set these settings:
LOGIN_REDIRECT_URL
LOGIN_URL
LOGOUT_URL

Then the middleware would be:

class MaintenanceMiddleware(object):
 def process_request(self, request):
   from django.conf import settings
   from django.http import HttpResponseRedirect


   is_login = request.path in (
 settings.LOGIN_REDIRECT_URL,
 settings.LOGIN_URL,
 settings.LOGOUT_URL)
   if ((not is_login) and
   settings.MAINTENANCE and
   (not request.user.is_authenticated())):
  return HttpResponseRedirect("/maintenance/")
   return None

More:
http://www.djangoproject.com/documentation/request_response/#attributes
http://www.djangoproject.com/documentation/settings/#login-redirect-url

Note that those settings are new in the Django dev version (after
0.96).  Of course you could add them to your own settings file, same
as MAINTENANCE.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Maintainance Middleware

[Christian M Hoeppner]

> You're more likely to get working code if all the requirements are stated. 
> :)

Yeah, you're right, Jeremy. Thank you a lot for your help.

I wonder... There isn't a way in a middleware to access some name path from 
the urlconf, is there? That way I wouldn't have to set those settings, by 
letting the admin-path bypass the maintenance middleware.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Maintainance Middleware

[Jeremy Dunck]

On 5/16/07, Christian M Hoeppner <[EMAIL PROTECTED]> wrote:
...
> I wonder... There isn't a way in a middleware to access some name path from
> the urlconf, is there? That way I wouldn't have to set those settings, by
> letting the admin-path bypass the maintenance middleware.

Not as far as I can see now, but it does seem like a good idea.

New ticket:
http://code.djangoproject.com/ticket/4311

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Maintainance Middleware

[Christian M Hoeppner]

Just for the record:

** settings.py in $project_path:

# Maintenance Mode Switch
MAINTENANCE = True

# Login paths
LOGIN_REDIRECT_URL = '/admin/'
LOGIN_URL = '/admin/'
LOGOUT_URL = '/admin/logout/'

# This will be shown to unauthorised users when the site is in maintenance 
mode
MAINTENANCE_PATH = '/maintenance/'

** middleware.py in $project_path:

class MaintenanceMiddleware(object):
def process_request(self, request):
from django.conf import settings
from django.http import HttpResponseRedirect


is_login = request.path in (
settings.LOGIN_REDIRECT_URL,
settings.LOGIN_URL,
settings.LOGOUT_URL,
settings.MAINTENANCE_PATH,
)
if ((not is_login) and settings.MAINTENANCE and (not 
request.user.is_authenticated())):
return HttpResponseRedirect(settings.MAINTENANCE_PATH)
return None

I have added the MAINTENANCE_PATH setting, and included it in the path check. 
If this one is not checked to be false, we get an endless redirect loop.

I'll be posting this into my new blog (as soon as I get it up) and if you like 
it and find it usefull, you might also tell me to post it at Django Snippets.

Thank you everyone!

Chris Hoeppner
www.pixware.org

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: middleware needed

[Eugene Lazutkin]

Lawgon,

Are you sure you run admin with correct settings? Please note that admin 
requires myproject.settings.admin, while the rest of the site requires 
myproject.settings.main (see 
http://www.djangoproject.com/documentation/tutorial1/).

Cheers,

Eugene

"lawgon" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
>
> I set up a django installation, but when i tried to run the admin
> thingie, i get this message:
> Traceback (most recent call last):
>
>  File
> "/usr/local/lib/python2.4/site-packages/django/core/handlers/base.py",
> line 60, in get_response
>response = middleware_method(request, callback, param_dict)
>
>  File
> "/usr/local/lib/python2.4/site-packages/django/middleware/admin.py",
> line 41, in process_view
>    assert hasattr(request, 'session'), "The admin requires session
> middleware to be installed. Edit your MIDDLEWARE_CLASSES setting to
> insert 'django.middleware.sessions.SessionMiddleware' before %r." %
> self.__class__.__name__
>
> AssertionError: The admin requires session middleware to be installed.
> Edit your MIDDLEWARE_CLASSES setting to insert
> 'django.middleware.sessions.SessionMiddleware' before
> 'AdminUserRequired'.
>
> i edited admin.py in the middleware directory and added this:
>
> MIDDLEWARE_CLASSES = (
>"django.middleware.sessions.SessionMiddleware",
>"django.middleware.admin.AdminUserRequired",
>"django.middleware.common.CommonMiddleware",
> )
>
> before the lines AdminUserRequired. But there is no change - same error
> is coming up. Any clues?
>
> 

Validator app+middleware

[Luke Plant]

Hi all,

This evening I wrote an app and middleware to help me with
development of my Django project.  It validates all the HTML generated
by your Django project, and logs any failures, including the original
request object, the response object and the errors. It's more useful
than a crawler because this will catch everything (including pages
generated by a POST request etc), and it could also be configured to
validate CSS or any other mimetype if you wanted. 

It currently does validation synchronously, which adds about 1/4 a
second to the page load time on my machine, but it's well worth it.  It
uses the command line program 'validate' by Liam Quinn, but can be
configured to use anything that works similarly.  In fact, I've wrote a
wrapper script that calls 'validate' and also beeps at me if validate
fails, so I get instant feedback if I've created any invalid HTML.

Here is the obligatory screenshot of it finding HTML errors in
itself:

http://files.lukeplant.fastmail.fm/public/validator_app_sshot.png

(these are fixed now of course :-)
The interface has actually progressed from than screen shot now, but
it's still very simple - just enough to view the list, view details,
delete items.

Anyway, if anyone else wants this, let me know.  It ended up taking up
the whole evening and I didn't have chance to package it up, so I'm
only going to bother if there is some demand.  I've only tested on
Linux, but I imagine it would work on Windows, but would probably be
significantly slower due to starting new processes being quite a
bit slower on Windows.

Regards,

Luke

-- 
"Oh, look. I appear to be lying at the bottom of a very deep, dark 
hole. That seems a familiar concept. What does it remind me of? Ah, I 
remember. Life."  (Marvin the paranoid android)

Luke Plant || L.Plant.98 (at) cantab.net || http://lukeplant.me.uk/

mproperlyConfigured: Middleware module

[Patrick Martini]

I have some problem with Django and mod_python (3.1.3.3).
With runserver all works fine but qith apache I receive always this message.

Mod_python error: "PythonHandler django.core.handlers.modpython"

Traceback (most recent call last):

  File "/usr/lib/python2.3/site-packages/mod_python/apache.py", line 299, in 
HandlerDispatch
result = object(req)

  File "/usr/lib/python2.3/site-packages/django/core/handlers/modpython.py", 
line 161, in handler
return ModPythonHandler()(req)

  File "/usr/lib/python2.3/site-packages/django/core/handlers/modpython.py", 
line 128, in __call__
self.load_middleware()

  File "/usr/lib/python2.3/site-packages/django/core/handlers/base.py", line 
36, in load_middleware
raise exceptions.ImproperlyConfigured, 'Middleware module "%s" does not 
define a "%s" class' % (mw_module, mw_classname)

ImproperlyConfigured: Middleware module "django.contrib.sessions.middleware" 
does not define a "SessionMiddleware" class

-- 
__
email:[EMAIL PROTECTED]
http://patrick.pupazzo.org
__




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Problem with middleware

[Guillermo Fernandez Castellanos]

Hi,

Seems like last time I was not that clear, so here is what I want to
do: I want to keep track of the users that visit my site, keeping in
the DB what IP addresses visited my site, when, ... I define a visit
as a click on one of my pages, given that this visit is done a certain
time after the last visit (30 minutes, 1 hour, 1day,... that can be
choosen).

I've decided to keep in the cookies, through the session middleware,
the value of the last visit. I do this with the request.session in the
process_view of a personal middleware I am trying to develop:

class IpMiddleware:
   def _add_ip(this_ip):
# Adds IP and Visit to database
   [...]
   def process_view(self, request, view_func, view_args, view_kwargs):
   last_visit=request.session.get('sysvortex_last_visit', datetime.now())
   difference=datetime.now()-last_visit
   if difference > timedelta(minutes=30):
   self._add_ip(request.META['REMOTE_ADDR'])
   return None

My problem is, I can not make the request.session to store my value.
No matter how many time I wait or what I do, 'difference' always is
(almost) 0. It seems to me that when I do
request.session.get('sysvortex_last_visit', datetime.now()) the value
is not actually saved, which seems strange.

I am struggling with this for a few days now, so any help or pointer
is higly appreciated, thanks!

G

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: SSL Middleware

[[EMAIL PROTECTED]]

looks handy!

so now we can specify our urls for, say a login screen, and enjoy ssl
for that page only without explicit redirects. Also there is no way for
a user to request an unsecure version of that page if one is not
explicitly offered.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: SSL Middleware

[Antonio Cavedoni]

On 8 Oct 2006, at 5:27, [EMAIL PROTECTED] wrote:
> so now we can specify our urls for, say a login screen, and enjoy  
> ssl for that page only without explicit redirects. Also there is no  
> way for a user to request an unsecure version of that page if one  
> is not explicitly offered.

Yes, unless they find a way to work around the middleware, that is ;-)

This also means there is no ambiguity over the canonical URI of a page.

I’m thinking about modifying the HTTPS_PATHS setting to accept  
regular expressions instead of just strings, that would allow for  
even more flexibility. I’m still thinking, though, maybe it’s overkill.

Cheers.
-- 
Antonio



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: SSL Middleware

[mukappa]

Very timely.  I was just looking for something like this.

One observation.  When redirecting to https elsewhere in the django
code I see this call, "django.http.get_host(request)" for resolving the
host portion.

Thanks.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: SSL Middleware

[Antonio Cavedoni]

On 9 Oct 2006, at 21:07, mukappa wrote:
> One observation.  When redirecting to https elsewhere in the django  
> code I see this call, "django.http.get_host(request)" for resolving  
> the host portion.

Good call, that function checks for HTTP_X_FORWARDED_HOST instead of  
just request.META['HTTP_HOST'] as I’m doing.

I tweaked the SSL middleware to use it, thanks for the heads up!

Cheers.
-- 
Antonio



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: middleware or view ?

[Russell Keith-Magee]

On Sun, Oct 19, 2008 at 5:19 AM, PonasNiekas <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm about to write an app, which is going to do long running (~1 to
> ~60 minutes) calculations (meanwhile, the user who triggered the
> calculation will get message like "calculation in progress" or smth).
>
> I'm wondering what is the right place or best practice to do such
> calculations, custom middleware or view ?

Neither.

A view isn't really the right place to be performing long-lived
calculations. While the calculation is being performed, the user won't
have any feedback; on top of that, it will hold open a connection on
your webserver and lock out any other possible connections to the
webserver. It doesn't really matter where in the response chain the
calculation occurs (view, middleware, or otherwise) - the outcome will
be the same.

This isn't really a problem that can be solved with a single view. You
need to look at breaking up the problem a little bit:
1) The user visits a view that registers that a long lived job needs
to be performed and adds the job to a queue
2) A process that runs in the background, independent of the
webserver, processing jobs that have been queued
3) A view that can poll the queue to inspect the status of a given job
4) A view that shows the queue status to the user.

When the user visits view 1, the job is queued, and the user is
redirected to view 4. View 4 uses AJAX style requests to poll view 3
to provide status updates until the job has been completed. The main
work is done by task 2, which runs independent of the webserver. This
keeps all http connections short lived (which frees up web server
resources) and provides the ability for continuous feedback on job
progress.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: middleware or view ?

[PonasNiekas]

Thanks Russ for the replay. Your idea would certainly work and I agree
that
doing calculations outside django/web server makes sense. I will
probably
and up doing the way you described.

On the other hand, having the whole thing in django without any
external
components would kinda be nice.. Would it help if calculations doing
class
would be threaded ?

--
PonasNiekas
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: middleware or view ?

[Russell Keith-Magee]

On Sun, Oct 19, 2008 at 7:27 PM, PonasNiekas <[EMAIL PROTECTED]> wrote:
>
> Thanks Russ for the replay. Your idea would certainly work and I agree
> that
> doing calculations outside django/web server makes sense. I will
> probably
> and up doing the way you described.
>
> On the other hand, having the whole thing in django without any
> external
> components would kinda be nice.. Would it help if calculations doing
> class
> would be threaded ?

Threads won't help with your problem. It doesn't matter if the Django
code that does the processing is multithreaded. The connection between
the web server and Django will only be a single thread. Background
processing is the only real solution here.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: middleware or view ?

[Dmitry Dzhus]

PonasNiekas wrote:

> I'm about to write an app, which is going to do long running (~1 to
> ~60 minutes) calculations (meanwhile, the user who triggered the
> calculation will get message like "calculation in progress" or smth).
>
> I'm wondering what is the right place or best practice to do such
> calculations, custom middleware or view ?

How are you going to fit long-lasting calculations in «request/response»
model at all?

I'd perform calculations separately, using Django to provide user views
to launch calculation, see its progress and obtain results. However, a
program which will actually do the job might make use of Django's DB
interface to get a list of tasks to perform, store calculation progress
and results in your database so you could access it from you Django
application.
-- 
Happy Hacking.

http://sphinx.net.ru
む


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: creating django middleware

[Steve Holden]

ershadul wrote:
> Dear all,
> please consider the following code-block:
>
> class SQLAlchemySessionMiddleware(object):
> """
> This class instantiates a sqlalchemy session and destroys
> """
> def process_request(self, request):
> request.db_session = session()
> return None
>
>   
The last statement in your method is completely redundant, and I'd
suggest you remove it.

How are you verifying that your middleware's "process_request()" method
is being called?
[...]

regards
 Steve


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: creating django middleware

[Jeff FW]

I also wrote middleware for SQLAlchemy--I'd post it, but it depends on
other libraries that I wrote that I can't really share.  What I found
is that, at least while using the dev server, the process_response
method would get called when serving media files, even if the
process_request hadn't.  So, simple solution: wrap the session_destroy
call in a try/except block.  Here's mine:

def process_response(self, request, response):
try:
request.db_session.commit()
request.db_session.close()
except AttributeError:
pass
return response

Also, may I suggest adding a process_exception method?  Here's mine:

def process_exception(self, request, exception):
request.db_session.rollback()
request.db_session.close()

-Jeff

On Nov 12, 7:18 am, ershadul <[EMAIL PROTECTED]> wrote:
> Dear all,
> please consider the following code-block:
>
> class SQLAlchemySessionMiddleware(object):
>     """
>     This class instantiates a sqlalchemy session and destroys
>     """
>     def process_request(self, request):
>         request.db_session = session()
>         return None
>
>     def process_response(self, request, response):
>         session_destroy(request.db_session)
>         return response
>
> Consider that session() is method that returns a new object sqlalchemy
> session.
> I want to inject it before view is processed and destroy it upon
> exiting the view.
>
> I have added the path of this middleware class before XView
> middleware in settings.py.
> But i got a error that
> request has not attribute 'db_session' ( process_response function)
> How can i do it?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: creating django middleware

[ershadul]

Dear ,
I dont know whether my process_request() is being called or not?
Can you inform me please, how can i verify that my middleware's
process_request() is called ?

On Nov 12, 4:42 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> ershadul wrote:
> > Dear all,
> > please consider the following code-block:
>
> > class SQLAlchemySessionMiddleware(object):
> >     """
> >     This class instantiates a sqlalchemy session and destroys
> >     """
> >     def process_request(self, request):
> >         request.db_session = session()
> >         return None
>
> The last statement in your method is completely redundant, and I'd
> suggest you remove it.
>
> How are you verifying that your middleware's "process_request()" method
> is being called?
> [...]
>
> regards
>  Steve
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: creating django middleware

[Steve Holden]

ershadul wrote:
> Dear ,
> I dont know whether my process_request() is being called or not?
> Can you inform me please, how can i verify that my middleware's
> process_request() is called ?
> 
> On Nov 12, 4:42 am, Steve Holden <[EMAIL PROTECTED]> wrote:
>> ershadul wrote:
>>> Dear all,
>>> please consider the following code-block:
>>> class SQLAlchemySessionMiddleware(object):
>>> """
>>> This class instantiates a sqlalchemy session and destroys
>>> """
>>> def process_request(self, request):
>>> request.db_session = session()
>>> return None
>> The last statement in your method is completely redundant, and I'd
>> suggest you remove it.
>>
>> How are you verifying that your middleware's "process_request()" method
>> is being called?
>> [...]

Try putting print statements in your code. Running the test server, of
course, so you will see any console output.

regards
 Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: creating django middleware

[ershadul]

Dear Steve Holden,
Please consider the following block i wrote:

def process_request(self, request):
request.db_session = session()
request.db_session.time_stamp = str(datetime.datetime.now())
print 'process_request', request.db_session.time_stamp

def process_response(self, request, response):
try:
print 'process_response', request.db_session.time_stamp
session_destroy(request.db_session)
except AttributeError:
print 'process_response: db_session not found'
#pass
return response

 For some links i got the message 'db_session not found' , not for
all request.
that is for some requests process_response is called at first.
Look at the output at console:
These are OK.
Django version 1.0-alpha-SVN-unknown, using settings
'divineba.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CTRL-BREAK.
process_request 2008-11-14 14:33:07.437000
process_response 2008-11-14 14:33:07.437000
[14/Nov/2008 14:33:07] "GET /journal/view HTTP/1.1" 200 22616
process_request 2008-11-14 14:33:07.734000
process_response 2008-11-14 14:33:07.734000
[14/Nov/2008 14:33:07] "GET /js/jquery.js HTTP/1.1" 304 0
process_request 2008-11-14 14:33:07.781000
process_response 2008-11-14 14:33:07.781000
[14/Nov/2008 14:33:07] "GET /js/jquery.autocomplete.js HTTP/1.1" 304 0

But for some links we got the following output:

Django version 1.0-alpha-SVN-unknown, using settings
'divineba.settings'
Development server is running at http://127.0.0.1:8000/
Quit the server with CTRL-BREAK.
process_response process_response: db_session not found
[14/Nov/2008 14:36:14] "GET /account/chart HTTP/1.1" 301 0
process_request 2008-11-14 14:36:14.531000
process_response 2008-11-14 14:36:14.531000
[14/Nov/2008 14:36:14] "GET /account/chart/ HTTP/1.1" 200 6717

Look at the 4th line:
 "process_response process_response: db_session not found"

Why for some links process_response is called before process_request?
Logically each process_request is called before process_response.
Can you provide any suggestion please ?

On Nov 13, 6:18 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> ershadul wrote:
> > Dear ,
> > I dont know whether my process_request() is being called or not?
> > Can you inform me please, how can i verify that mymiddleware's
> > process_request() is called ?
>
> > On Nov 12, 4:42 am, Steve Holden <[EMAIL PROTECTED]> wrote:
> >> ershadul wrote:
> >>> Dear all,
> >>> please consider the following code-block:
> >>> class SQLAlchemySessionMiddleware(object):
> >>>     """
> >>>     This class instantiates a sqlalchemy session and destroys
> >>>     """
> >>>     def process_request(self, request):
> >>>         request.db_session = session()
> >>>         return None
> >> The last statement in your method is completely redundant, and I'd
> >> suggest you remove it.
>
> >> How are you verifying that yourmiddleware's"process_request()" method
> >> is being called?
> >> [...]
>
> Try putting print statements in your code. Running the test server, of
> course, so you will see any console output.
>
> regards
>  Steve
> --
> Steve Holden        +1 571 484 6266   +1 800 494 3119
> Holden Web LLC              http://www.holdenweb.com/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: creating django middleware

[Malcolm Tredinnick]

On Fri, 2008-11-14 at 00:39 -0800, ershadul wrote:
> Dear Steve Holden,
> Please consider the following block i wrote:
> 
> def process_request(self, request):
> request.db_session = session()
> request.db_session.time_stamp = str(datetime.datetime.now())
> print 'process_request', request.db_session.time_stamp
> 
> def process_response(self, request, response):
> try:
> print 'process_response', request.db_session.time_stamp
> session_destroy(request.db_session)
> except AttributeError:
> print 'process_response: db_session not found'
> #pass
> return response
> 
>  For some links i got the message 'db_session not found' , not for
> all request.
> that is for some requests process_response is called at first.
> Look at the output at console:
> These are OK.
> Django version 1.0-alpha-SVN-unknown, using settings
> 'divineba.settings'
> Development server is running at http://127.0.0.1:8000/
> Quit the server with CTRL-BREAK.
> process_request 2008-11-14 14:33:07.437000
> process_response 2008-11-14 14:33:07.437000
> [14/Nov/2008 14:33:07] "GET /journal/view HTTP/1.1" 200 22616
> process_request 2008-11-14 14:33:07.734000
> process_response 2008-11-14 14:33:07.734000
> [14/Nov/2008 14:33:07] "GET /js/jquery.js HTTP/1.1" 304 0
> process_request 2008-11-14 14:33:07.781000
> process_response 2008-11-14 14:33:07.781000
> [14/Nov/2008 14:33:07] "GET /js/jquery.autocomplete.js HTTP/1.1" 304 0
> 
> But for some links we got the following output:
> 
> Django version 1.0-alpha-SVN-unknown, using settings
> 'divineba.settings'
> Development server is running at http://127.0.0.1:8000/
> Quit the server with CTRL-BREAK.
> process_response process_response: db_session not found
> [14/Nov/2008 14:36:14] "GET /account/chart HTTP/1.1" 301 0
> process_request 2008-11-14 14:36:14.531000
> process_response 2008-11-14 14:36:14.531000
> [14/Nov/2008 14:36:14] "GET /account/chart/ HTTP/1.1" 200 6717
> 
> Look at the 4th line:
>  "process_response process_response: db_session not found"
> 
> Why for some links process_response is called before process_request?
> Logically each process_request is called before process_response.
> Can you provide any suggestion please ?

There's no guarantee that the request method is going to be called. If
another middleware earlier in the stack returned a response, the
remainder of the middleware stack (including your process_request()
method) is skipped -- in the request processing path.

However, at that point, the full response processing path, including all
middleware functions, is executed. So if something, say, the cache
middleware intercepted the request before it got to your middleware,
your request handler won't be run. But your response handler will be.
You need to be able to handle that situation (your response handler
needs to check that something like db_session exists before accessing
it).

Regards,
Malcolm


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

How do test Middleware

[shabda]

I want to write some test for my middleware seperate from the views
that would be using them. So I am using this snippet
http://www.djangosnippets.org/snippets/963/ to get a request, and
calling my middleware with it to test it, but it looks a little
hackish to me. Is there a better way?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Order of Middleware

[Steve Holden]

Peter wrote:
> When I run django admin and do startproject I get a settings file that
> has:
>
> MIDDLEWARE_CLASSES = (
> 'django.middleware.common.CommonMiddleware',
> 'django.contrib.sessions.middleware.SessionMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> )
>
> In the global_settings.py file there is:
>
> # List of middleware classes to use.  Order is important; in the
> request phase,
> # this middleware classes will be applied in the order given, and in
> the
> # response phase the middleware will be applied in reverse order.
>
> MIDDLEWARE_CLASSES = (
> 'django.contrib.sessions.middleware.SessionMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> # 'django.middleware.http.ConditionalGetMiddleware',
> # 'django.middleware.gzip.GZipMiddleware',
> 'django.middleware.common.CommonMiddleware',
> )
>
> Order is declared to be important so which is the correct order?
>
>   
I'd assume that they are installed in the correct order until you have
evidence to the contrary.

regards
 Steve


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Order of Middleware

[Malcolm Tredinnick]

On Mon, 2008-11-17 at 11:53 -0800, Peter wrote:
> When I run django admin and do startproject I get a settings file that
> has:
> 
> MIDDLEWARE_CLASSES = (
> 'django.middleware.common.CommonMiddleware',
> 'django.contrib.sessions.middleware.SessionMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> )
> 
> In the global_settings.py file there is:
> 
> # List of middleware classes to use.  Order is important; in the
> request phase,
> # this middleware classes will be applied in the order given, and in
> the
> # response phase the middleware will be applied in reverse order.
> 
> MIDDLEWARE_CLASSES = (
> 'django.contrib.sessions.middleware.SessionMiddleware',
> 'django.contrib.auth.middleware.AuthenticationMiddleware',
> # 'django.middleware.http.ConditionalGetMiddleware',
> # 'django.middleware.gzip.GZipMiddleware',
> 'django.middleware.common.CommonMiddleware',
> )
> 
> Order is declared to be important so which is the correct order?

Good catch. Fortunately, in this case it doesn't really matter. The
version in global_settings is very slightly less efficient, but the work
done by session and auth middlewares is reasonably independent to what
the common middleware does.

The reason the latter version is less efficient is because if the common
middleware needs to make a redirect due to adding a trailing slash or
something like that, there's really no need to have gone through the
session and authentication process. I guess there's possibly some
odd-looking setup possible where authentication fails on the passed in
URL but passes on the version common middleware redirects to and thus
the first order is more accurate for that reason, but it would be an
unlikely situation.

In any case, if you would be kind enough to open a ticket for this,
we'll switch around the global version to be consistent.

Regards,
Malcolm



--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Custom Middleware TypeError exception

[Chris Smith]

Found an oddity - possibly in my code.  Can't seem to work around it.

Code in question (current multi-tenant middleware implementation):

middleware.py ..

from projectname.models import Tenant, HostEntry
from django.http import HttpResponseNotFound
from django.core.exceptions import ObjectDoesNotExist

class MultiTenantMiddleware(object):
"""Multi tenant middleware"""
def process_request(self, request):
http_host = request.META['HTTP_HOST']
try:
host_entry = HostEntry.objects.get(host=http_host)
except ObjectDoesNotExist:
return HttpResponseNotFound("Host not found")
request.tenant = host_entry.tenant
return None

-

Exception details 

Environment:

Request Method: GET
Request URL: http://localhost:8000/
Django Version: 1.0.2 final
Python Version: 2.6.0
Installed Applications:
['django.contrib.sessions', 'productname']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
 'vhdesk.middleware.MultiTenantMiddleware',
 'django.contrib.sessions.middleware.SessionMiddleware',
 'django.contrib.auth.middleware.AuthenticationMiddleware')


Traceback:
File "C:\Python26\Lib\site-packages\django\core\handlers\base.py" in
get_response
  86. response = callback(request, *callback_args,
**callback_kwargs)

Exception Type: TypeError at /
Exception Value: test() takes exactly 1 argument (2 given)

-

Only occurs after i "return None".  If the host entry is not found it
works correctly.

Any ideas?  Is it something silly I've done?

Cheers,

Chris.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: middleware import errors

[Malcolm Tredinnick]

On Sat, 2008-12-13 at 05:07 -0800, Vladimir Kirillov wrote:
> using django-1.0.2 with apache-1.3 (OpenBSD), python-2.4, fastcgi and
> py-flup-1.0 from yesterday's mercurial tip

By the way, for the future, you'll probably want to find a way to work
out what the real subversion revision is that your checkout corresponds
to. I don't know where you are doing the mercurial checkout from, but
the canonical reference is always the subversion repository. If you are
ever reporting a bug that might have been introduced recently, it will
be very helpful, practically compulsory, to know which subversion
revisions are involved.

>  throws these logs into
> error-log and 500 to any requests:
> apache error logs:
>  Traceback (most recent call last):
>File "../lib/flup/server/fcgi_base.py", line 558, in run
>File "../lib/flup/server/fcgi_base.py", line 1116, in handler
>File "../lib/django/core/handlers/wsgi.py", line 228, in __call__
>File "../lib/django/core/handlers/base.py", line 40, in
> load_middleware
>  ImproperlyConfigured: Error importing middleware
> django.middleware.common: "No module named common"
> 
> (sometimes can be caused on other modules)

It's possible your Python path is not set correctly for the process that
is running flup, but that seems unlikely, since importing wsgi.py and
base.py requires importing things from other places in Django.

My best guess would be that permissions are somehow set differently on
some of the directories, so they cannot be read by the process and user
running flup.

Regards,
Malcolm



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

Middleware, exceptions and POST

[Roman Odaisky]

Hi everyone,

I have a (technical) problem with middleware, and also I’d be grateful to hear 
some suggestions about the general workflow. Doubtless all of you are 
familiar with a topic as simple as POST handling, and maybe some of you have 
improvements over the usual Django approach.

So, I have a web application which (surprise!) has forms and is DB-driven. 
When designing the backend I considered the Django standard pattern for 
forms[1] and found it has problems such as coupling of unrelated things like 
showing a view and processing a form, and also it doesn’t provide a simple 
means of showing the same form in different places but having one POST 
handler.

Instead I chose another approach:
1. Every POST goes to the current URL ();
2. On the server side, the URL of a POST is disregarded. The appropriate 
handler is chosen by the value of a special parameter (I called 
it “submission”, );
3a. If processing is successful, an HTTP 302 redirect is issued to the same 
URL;
3b. If not, form.errors are attached to the request object and the appropriate 
view is called, which has the opportunity of presenting the same form once 
more, specifying the errors.

To implement this I wrote a middleware class which is as simple as

class post_middleware(object):
def process_request(self, request):
if request.method != "POST":
return None

if "submission" not in request.POST:
return None

try:
# successful POST always ends with a redirect
return HttpResponseRedirect(do_submission(request))
except invalid_form, e:
request._dict_form_errors = dict_errors(e.form.errors)
return None

So, it tries to handle the submission, and if that fails with an invalid form 
error, it returns None to let Django proceed with its usual procedure to find 
the appropriate view, which will then display the form again, complete with 
the erroneous input found in request.POST and the errors taken from the 
request object.

The implementation has not, however, been entirely successful.

So far Django modularity has allowed me to replace entire components with my 
own ones, or with 3rd party ones (like StringTemplate, which is superior to 
Django template engine), and integration was seamless. But I got all kinds of 
problems with this custom middleware. First of all, exceptions other than my 
custom invalid_form are no longer handled by the yellow screen of 
technical_500_response. Also, the transaction middleware no longer performs 
rollback on exceptions.

So could anyone please tell me how do I make Django handle middleware 
exceptions (do I have to wait until bug #6094 is fixed?), and also whether 
there’s another approach to handling form submissions with the above benefits 
and less drawbacks?

References:
[1] http://docs.djangoproject.com/en/dev/topics/forms/#using-a-form-in-a-view

-- 
TIA
Roman.


smime.p7s
Description: S/MIME cryptographic signature

Question about transaction middleware

[Sebastian Bauer]

Hi, i have one simple question, why this middleware leave transaction in 
managed mode? i think this create a little hole to execute queries we 
dont want to execute.

Thanks for answer

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

Disabling middleware for tests

[davenaff]

What is the best way to disable a specific middleware when running
django tests?

This ticket was designated wontfix, so I get test failures on the auth
tests every time I run our test suite:
http://code.djangoproject.com/ticket/9172#comment:12

I'd prefer not to have to edit settings.py every time I run our tests,
and of course I don't like tests that fail...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---