I didn't really like the current state of iPhone/Mobile redirect middleware mainly because I wanted something that was closer to twitters use case. So I came up with this. I don't think it a great snippet and I will probably fix it in the near future. But it works.
Middleware for implementing "hours of operation" for a website. In use (as configured here) on http://ianab.com/.
I wanted a global way to filter profanity w/out having to modify every model, view, or form. While middleware takes overhead, this technique is intended mainly for sites w/few postbacks. Hopefully this snippet will lead to more/better techniques in the comments below. Usage (settings.py): MIDDLEWARE_CLASSES = ( 'PROJECT_NAME.FILE_NAME.ProfanityFilterMiddleware', )
Sometimes when a Django site's authentication backend goes down, a login will fail with a 500 error. This has happened to me when using an LDAP backend for authentication. A glitch with the settings, or ldap temporarily disappearing can make logins flake out for a short period of time. That's fine, but when a 500 error occurs it e-mails detailed information about the error to the ADMINS. We like this behavior for most errors, but it is quite frustrating when it is a login form with a password as part of a POST. If it is one of us who gets our password e-mailed out, it's even more frustrating. It hits a mailing list first, and goes to the archives to be stored in plain text. It goes to several e-mail inboxes, some of which are not local inboxes. I decided that enough was enough. Drop this middleware in, and it will change a "password" field in the POST to twenty asterisks. This was the default way to display other sensitive settings on the DEBUG page, so I figured I'd be consistant with that. This snippet is distributed under the GPLv3 License http://www.gnu.org/licenses/gpl-3.0-standalone.html
This is like snippet 786, except it does it at the middleware layer, so you don't have to reference it in every view. Super simple. refer to: http://www.djangosnippets.org/snippets/786/
This is a simple middleware that redirects the exactly URL requested with the correct domain. It is useful when you have more than one domain (most of cases with "www." or IP) to access a website. To make it works, download the snippet file as the name "permanent_redirect.py" and add its path as the first item in MIDDLEWARE_CLASSES setting in settings.py. Later you must inform a setting called `HTTP_HOST_DOMAIN` with the correct domain.
Activate this middleware and define `LOG_FORMAT` & `LOG_ROOTS` in your `settings.py`. Then you can use Python's `logging` module for easy logging within your application.
Uses the Message model in django.contrib.auth.models to display a welcoming login message.
Works like the [PREPEND_WWW](http://www.djangoproject.com/documentation/settings/#prepend-www) setting but, instead of adding, it removes the www. Usage: In the settings file add the UrlMiddleware to the middleware list and set REMOVE_WWW = True
This is another example use of the [exception middleware](http://www.djangosnippets.org/snippets/638/). It shows how to log exceptions to a file. Someone wanted to do this to avoid DOS-ing the email server in case of a silly error. (untested.)
**How to use**: 1. Install [**PyFacebook** package](http://wiki.developers.facebook.com/index.php/PythonPyFacebookTutorial). 2. After make all steps in tutorial above, put this code in your app's models.py module (you maybe prefer split it and put the middleware class in some other file). 3. Put the FacebookUserMiddleware python-path in the MIDDLEWARE_CLASSES in your settings.py (after facebook.djangofb.FacebookMiddleware). You probably will add some fields to FacebookUser model class :)
Often, you may register more than one domain name for your website, which may have a primary domain of *mysite.com.au*: 1. mysite.com 2. my-site.com 3. mysite.net 4. mysite.co.uk For SEO and brand awareness reasons, (remember: every page should have exactly one URL) you want every visitor to end up on your primary domain, *mysite.com.au*. This middleware checks the HTTP_HOST for all incoming requests, and sends the user to http://www.mysite.com.au/ if they've managed to hit another domain.
A little tiny middleware that, when used in multilingual sites, will make Django I18N ignore any `Accept-Language` headers in the request, thus ensuring that every first-time visitor (with no explicit language preference set via session or cookie) will see the site in the language specified by `settings.LANGUAGE_CODE`. (Please note that I think that overriding user preferences is generally a bad practice, but I had my reasons to use it :) )
Mechanism to obtain a `request.user` object without the `request` object itself. Requires `LocalUserMiddleware` in `MIDDLEWARE_CLASSES` settings variable. **Important**: works under assumption that within a web server each request is handled by a separate thread (as for example in the Apache HTTP server). **Beware**: [security threat](http://code.djangoproject.com/wiki/CookBookThreadlocalsAndUser), although ["thread locals only appears to be a security threat if a system has already been seriously compromised, at which point there'd be easier attacks to execute"](http://groups.google.com/group/django-users/browse_thread/thread/e7af359d7d183e04). **Dev note**: works fine with one-threaded Django's development server, each request resets current user; no worries 'bout many media requests - they won't (at least shouldn't) be using Django on the production server. **Ref**: originally found in the gatekeeper app.
A patch (against django svn trunk [4649](http://code.djangoproject.com/browser/django/trunk/?rev=4649)) that allows users to log in with Basic HTTP Authentication i.s.o. login forms using some simple middleware (entire patch is ~50 lines). I was unaware of http://code.djangoproject.com/wiki/GenericAuthorization so I'm not sure about its usefulness in the long run. You can enable it by including 'django.contrib.auth.middleware.BasicAuthenticationMiddleware' in your MIDDLEWARE_CLASSES and then adding the following lines in your settings.py: BASIC_WWW_AUTHENTICATION = True WWW_AUTHENTICATION_REALM = "djangolures.com" Updated: See also http://code.djangoproject.com/ticket/3609 (patch now availble here as well).