Ordering middleware classes for Django-nonrel on GAE - django

Can anyone clarify how to order below middleware classes?
'mediagenerator.middleware.MediaMiddleware',
'autoload.middleware.AutoloadMiddleware',
'django.middleware.cache.UpdateCacheMiddleware',
.
.
.
'django.middleware.cache.FetchFromCacheMiddleware',
'google.appengine.ext.appstats.recording.AppStatsDjangoMiddleware',
In documents, every middleware in the top group is told to come first,
and both middleware in the bottom group is told to come last.
This is confusing.
Below is the whole list of middleware that I'm using:
'mediagenerator.middleware.MediaMiddleware',
'autoload.middleware.AutoloadMiddleware',
'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.csrf.middleware.CsrfViewMiddleware',
'django.middleware.csrf.CsrfResponseMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware',
'google.appengine.ext.appstats.recording.AppStatsDjangoMiddleware',
Any help and explanation will be appreciated.

Please check if everything is working:
'autoload.middleware.AutoloadMiddleware', # This is loading other modules, so it goes first because we want everything set before processing.
'mediagenerator.middleware.MediaMiddleware', # Serves/caches static files with urls starting with DEV_MEDIA_URL
'django.middleware.cache.UpdateCacheMiddleware', # Must be before other middleware that changes the header, so it seems that the right place for this is here
'google.appengine.ext.appstats.recording.AppStatsDjangoMiddleware', # Must be 'first' too. It collects stats of all middlewares below this. If you want stats from the middlewares above move it to the top
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.csrf.middleware.CsrfViewMiddleware',
'django.middleware.csrf.CsrfResponseMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware',

Related

Setting up local django environment for multiple domains

I'm trying to set up a Django application that will accept multiple subdomain URLs. I'd like to test this locally. Since I can't nail this first step of passing in a url that has a subdomain, I can't get to the second part (figuring out if the URLconf I've set up for django-subdomains is working). The middleware checks for a subdomain, and chooses a URLconf file based on that subdomain.
I've set the following configs in /etc/hosts. When I've got the server running, and I hit these URLs, I go to the real test.com.
127.0.0.1 payments.test.com
127.0.0.1 rampup.test.com
(in case it matters) django-subdomains middleware settings from settings.py:
SUBDOMAIN_URLCONFS = {
'payments': 'main.urls',
'rampup': 'rampup.urls'
}
MIDDLEWARE_CLASSES = (
'subdomains.middleware.SubdomainURLRoutingMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
# Uncomment the next line for simple clickjacking protection:
# 'django.middleware.clickjacking.XFrameOptionsMiddleware',
)
Try this:
0.0.0.0 payments.test.com
0.0.0.0 rampup.test.com

Django middleware: Isn't a middleware module error

I am using the middleware provided in https://gist.github.com/426829 to do cross site scripting.
However, when I add the middleware to MIDDLEWARE_CLASSES, I get the error:
ImproperlyConfigured: isn't a middleware module.
My MIDDLEWARE_CLASSES looks like this:
MIDDLEWARE_CLASSES = ('django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'TempMiddleware',)
I have not changed any code in the gist. process_request and process_response methods are there. I am on Ubuntu running the latest versions of Python and Django.
What's TempMiddleware? The name of the module, or the name of the class? As you can see with the other entries, you need the fully-qualified Python path of the actual class. If TempMiddleware is the name of the module, you need TempMiddleware.MyMiddlewareClass (and you should really follow PEP8 naming conventions) - and if it's the name of the class, you need my_module.TempMiddleware.
Edit:
TempMiddleware is not importable. It's the name of the class, you must put the entire import path.
E.g:
'django.contrib.auth.middleware.AuthenticationMiddleware'
and not
'AuthenticationMiddleware'
So if your class is in app_name/middleware.py, it should be
app_name.middlaware.TempMiddleware
It just mean that in your settings file, the variable MIDDLEWARE_CLASSES contains a list of modules in which one of the listed module is not a middleware.
Possible causes:
you added a middleware that doesn't declare middleware methods: fix that by removing the last middleware you added
you added a correct middleware but forget to put a coma at the end of the name, so strings are concatenated and it make django thinks 2 middlewares are in fact one: fix that by adding the missing coma

Using Django Cache Middleware causes contrib.auth unit tests to fail

Problem: When I add UpdateCacheMiddleware and FetchFromCacheMiddleware to my Django project, I get unittest failures. This is regardless of the CACHE_BACKEND I use (right now I am using locmem://, but the errors are the same when I use file:///path_to_cache)
My Middleware:
MIDDLEWARE_CLASSES = (
'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.cache.FetchFromCacheMiddleware',
)
All my test failures look like the one below: 'NoneType' object is unsubscriptable
======================================================================
Error: test_last_login (django.contrib.auth.tests.remote_user.RemoteUserTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File "C:\Python26\lib\site-packages\django\contrib\auth\tests\remote_user.py",
line 87, in test_last_login
self.assertNotEqual(default_login, response.context['user'].last_login)
TypeError: 'NoneType' object is unsubscriptable
I must be missing something (or doing something wrong) as I have searched around the web for this issue, but no one seems to have encountered it.
Steps to Reproduce:
Start a new django project (django-admin.py startproject myproject) and configure settings.py
Add CACHE_BACKEND to settings.py and add the two Cache Middlewares from Django
Run python manage.py test
Notes: There is only one test failure when using dummy:// cache and it is documented at: http://code.djangoproject.com/ticket/11640
The solution to the failing tests is to set CACHE_MIDDLEWARE_SECONDS to 0 (e.g. set this to be 0 in your dev environment). This will allow the django.contrib tests to all pass.

django internationalization doesn't work

I have created translation strings in the template and in the application view.
Then I ran:
django-admin.py makemessages -l it
and the file it/LC_MESSAGES/django.po has been created
I have now translated strings in the django.po file, and then I ran:
django-admin.py compilemessages
And I receive:
processing file django.po in /home/jobber/Desktop/library/books/locale/it/LC_MESSAGES
My settings.py looks like this:
LANGUAGE_CODE = 'it'
TEMPLATE_CONTEXT_PROCESSORS = ( "django.core.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n",
"django.core.context_processors.media", )
USE_I18N = True
MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware',
'django.middleware.locale.LocaleMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
)
but I still always see English text. Why?
Maybe your browser language is English. The LocaleMiddleware tries to detect the language based on this algorithm (i.e. Accept-Language HTTP header).
So you can either remove the LocaleMiddleware to avoid this or use the set_language redirect view.
In addition to the accepted answer: If you're using Firefox you can install Quick Locale Switcher to test your application with different languages (based on the browser language). It adds a button at the bottom of your screen where you can easily change your browser language.

Django Per-site caching using memcached

So I'm using per-site caching on a project and I've observed the following, which is kind of confusing. When I load a flat page in my browser then change it through admin and then do a refresh (within the cache timeout) there is no change in the page--as expected. However when I stat a new session in a different browser and load the page (still within the timeout) the app is hit instead of the cache, with the
Isn't the cache key generated from the URL? it seems that the session state is getting in there somewhere, which is causing a cache miss.
MIDDLEWARE_CLASSES = (
'django.middleware.cache.UpdateCacheMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.middleware.gzip.GZipMiddleware',
'django.middleware.http.ConditionalGetMiddleware',
'django.middleware.doc.XViewMiddleware',
'ittybitty.middleware.IttyBittyURLMiddleware',
'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware',
'maintenancemode.middleware.MaintenanceModeMiddleware',
'djangodblog.middleware.DBLogMiddleware',
'SSL.middleware.SSLRedirect', #SSL middleware to handle SSL
'django.middleware.cache.FetchFromCacheMiddleware',
)