Similar to [Profiling Middleware](http://www.djangosnippets.org/snippets/186/), but uses cProfile instead of hotshot. Append ?prof to the URL to see profiling output instead of page output.
Banning middleware with allow,deny functionality. Can select by User id/username and IP addresses. Returns a HttpResponseForbidden when banning requests. Banning by users is real nice because no matter which IP a pest comes from, they can never retrieve anything that they log into. Very handy for keeping out those unwanted pests! I personally developed this further to use a Ban model to keep track of different bans on different sites. Maybe ill post that eventually, but this runs as is with static vars. Implementation from [HvZ Source](http://www.hvzsource.com)
This allows you to define a 'prefilter' function in your view modules which will be invoked before any view in that same. This provides an easy place to decorate the request or modify arguments. For simplicity it doesn't allow configuration of the name of the prefilter function. I also skipped recursing into parent modules since that's somewhat edgecase.
Serving KML from your Django webapp to feed Google-earth isn't that hard, it's just some fun with templates, plus some headers. But serving a compressed version of your KML needs a trick. KMZ isn't just zipped KML. A good KMZ file is a zipped file that decompress to a file called 'doc.kml', which is a KML file. So, I suppose 'http://yourdomain.com/kml/' points to a view generating a well-formed KML. I even suppose that 'http://yourdomain.com/kmz/' points to the same view, but it will serve KMZ instead that KML: no change needed in your code! If your webapps serves more than one KML file you just need to append the new KMZ urls to your urls.py, pointing to the very same view serving the KML version. Then add that urls to the list in this middleware. As an example I included a 'http://yourdomain.com/kml/restricted/' to 'http://yourdomain.com/kmz/restricted/' conversion.
A middleware that parses the HTTP_ACCEPT header of a request. The request gets a new method called "accepts" that takes a string and returns True if it was in the list of accepted mime-types. It makes it possible to write views like: def exampleview(request): if request.accepts('application/json'): # return a json representation if request.accepts('text/html'): # return html Please note that with this middleware the view defines the priority of the mime-types, not the order in which they where provided in the HTTP-Header.
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 middleware checks for xhtml mimetypes if the browser supports a "application/xhtml+xml" response. If not, it converts the response headers to "text/html". To enable this middleware add it the the MIDDLEWARE_CLASSES setting and make sure it appears somewhere after GZipMiddleware, so that it's processed first.
This allows you to use a quick login forms outside of the django.contrib.auth.views.login view, the cookie will be deleted once you login.
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
When debugging AJAX with Firebug, if a response is 500, it is a pain to have to view the entire source of the pretty exception page. This is a simple middleware that just returns the exception without any markup. You can add this anywhere in your python path and then put it in you settings file. It will only unprettify your exceptions when there is a XMLHttpRequest header. Tested in FF2 with the YUI XHR. Comments welcome. EDIT: I recently changed the request checking to use the is_ajax() method. This gives you access to these simple exceptions for get requests as well (even though you could just point your browser there).
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.)
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/).
Have you ever felt the need to run multiple Django projects on the same memcached server? How about other cache backends? To scope the cache keys, you simply need to prefix. However, since a lot of Django's internals rely on `django.core.cache.cache`, you cannot easily replace it everywhere. This will automatically upgrade the `django.core.cache.cache` object if `settings.CACHE_PREFIX` is set to a string and the Middleware contains `ScopeCacheMiddleware`. A thread discussing the merging of this functionality into Django is available on [the dev mailing list](http://groups.google.com/group/django-developers/browse_thread/thread/d45edaafec56da2a). However, (as of now) nowhere in the thread does anyone mention the reason why this sort of treatment is needed: Many of Django's internal caching helpers use `django.core.cache.cache`, and will then conflict if multiple sites run on the same cache stores. Example Usage: >>> from django.conf import settings >>> from django.core.cache import cache >>> from scoped_caching import prefix_cache_object >>> settings.CACHE_PREFIX 'FOO_' # Do this once a process (e.g. on import or Middleware) >>> prefix_cache_object(settings.CACHE_PREFIX, cache) >>> cache.set("pi", 3.14159) >>> cache.get("pi") 3.14159 >>> cache.get("pi", use_global_namespace=True) >>> cache.get("FOO_pi", use_global_namespace=True) 3.14159 >>> cache.set("FOO_e", 2.71828, use_global_namespace=True) >>> cache.get("e") 2.71828 To Install: Simply add `ScopeCacheMiddleware` as a middleware and define `settings.CACHE_PREFIX` and enjoy!
Modified version of [Profiling Middleware](http://www.djangosnippets.org/snippets/186/) Prints profile results for method, additionally groups results by files and by modules (for django uses top level modules as groups). Works for Windows. Usage: append ?prof or &prof= to any URL pointing to django application after adding ProfileMiddleware to middlewares in yours settings.py. NOTICE: ProfileMiddleware uses hotshot profiler which is not thread safe.