DiggBarMiddleware
give diggbar users something to think about (http://daringfireball.net/2009/04/how_to_block_the_diggbar)
- middleware
give diggbar users something to think about (http://daringfireball.net/2009/04/how_to_block_the_diggbar)
Expanded version of [snippet 715](http://www.djangosnippets.org/snippets/715/ "Django snippets: Simple View Middleware to allow a Prefilter") to be more flexible. Updates: * 2009-04-24: Multiple filters now work correctly * 2009-03-22: Fixed bug * 2009-02-03: Simplified process.
Request-phase cache middleware that checks to make sure the Cache server is running. Starting it if it is not. This is run for every request, it checks to see if it can get a defined item out of the cache, if that fails it tries to set it. Failing that it decides the server is probably crashed, so goes though and attempts to connect to the server. Failing a connection it will launch a new server. This is probably not useful on large scale multi server deployments as they likely have their own testing for when services crash, but I am using it in a shared hosting environment where I have to run my own copy of memcache manually and cannot setup proper services testing, so I use this to just make sure the cache server is still running.
This middleware redirects the request for yoursite.com/feed/whatever/onefeed to your feedburner *onefeed* feed. Having ``FEEDBURNER = ('SomeName', ('blog', 'comments', 'tag1'))`` will use the feedburner feeds at http://feedproxy.google.com/SomeName/blog http://feedproxy.google.com/SomeName/comments http://feedproxy.google.com/SomeName/tag/tag1 you can add more tags, or even intersection and union of them the same way (thanks to piranha for the idea of a middleware) **Update:** now it works for tags as well
Snippet 240 is great, but it does not handle flatpages since flatpages are not technically a view. This operates on the request level, not the view level so it will handle flat pages. **Step 1** Add this class to your MIDDLEWARE_CLASSES **Step 2** Add an entry in settings.py which is a list of regex to match against urls that u want to have ssl: SSL_URLS = ( r'/login/', r'/home/', r'/super-sensitive-information/', )
Adds an 'X-Django-Request-Time' HTTP response header that times how long django spent processing the request.
If you feel nostalgic for the old days of crufty URLs, put this middleware somewhere in your Django app and add the first entry in settings.MIDDLEWARE_CLASSES as shown below. Keep in mind that you need to replace 'path.to' with the correct Python path to the middleware. MIDDLEWARE_CLASSES = ( 'path.to.RandomFileExtensionMiddleware', 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', ) Note: Although this works it's still a joke.
This simple middleware replaces all 'a href' links to the current page to the 'span' elements. This very usefule from the usability point of view. For example, user open in bowser page http://svetlyak.ru/blog/, and this middleware will replace all 'a' elements on this page, which refer to the '/blog/'. Because of this, link 'Blog' in the main menu, become a simple 'span'. Next, when user goes to the next page, a post with full comments list ('/blog/123/'), for example, the item 'Blog' in the main menu become a link again! To use this middleware, just add it to the list of middleware classes: MIDDLEWARE_CLASSES = ('utils.middleware.RemoveSelfLinks',)
This exception middleware abstracts the functionality of the builtin exception handling mechanisms, but makes them extensible by inheritance. Just add it (or some subclass) to the top of your active middleware list. You can use this to [make your admin emails more informative](http://www.djangosnippets.org/snippets/631/) or [log errors to a file](http://www.djangosnippets.org/snippets/639/).
Removes all target="..." attributes form hyperlinks, and then adds target="_blank" to all links starting with "http"
This is something we're using over at Curse to keep things clean and simple for our users. * We needed a url for any language code (which the domain provides) vs a cookie * We needed a to only store 2 letter codes in the db for each language (thus the key doesn't always match the code) This consists of two major modifications: * LANGUAGES in settings.py is a completely different format and would need changed based on your setup * the locale middleware has a couple absolute instances of where to point a user by default.
Apparently Internet Explorer (6 and 7) have a bug whereby if you blindly attach a PDF or some other file, it will choke. The problem lies in the Vary header (bug described in http://support.microsoft.com/kb/824847/en-us?spid=8722&sid=global). To use, just add to the beginning of your middleware classes.
Middleware for stripping all html comments from the response content before returning it to the client. This will also strip inline javascript with htmlcomments put around it!
On our site [Fornebuklinikken - A cosmetic surgeon in Norway](http://www.fornebuklinikken.no) we also have a domain [http://fornebuklinikken.com](http://www.fornebuklinikken.no) which should be using the 'en' language. We didn't wan't to use the standard locale lib, and wrote our own middleware which lookups the correct language corresponding to the domain (.no or .com) Any questions? Contact me on herman.schistad (at) gmail.com
A very basic Basic Auth middleware that uses a username/password defined in your settings.py as `BASICAUTH_USERNAME` and `BASICAUTH_PASSWORD`. Does not use Django auth. Handy for quickly securing an entire site during development, for example. In settings.py: BASICAUTH_USERNAME = 'user' BASICAUTH_PASSWORD = 'pass' MIDDLEWARE_CLASSES = ( 'app.module.BasicAuthMiddleware', #all other middleware )