Subdomain Middleware
This snippet will add the subdomain and domain to the request object for use in your views.
- middleware
- subdomain
This snippet will add the subdomain and domain to the request object for use in your views.
An example of using it in your settings.py: MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.middleware.doc.XViewMiddleware', 'util.loginmiddleware.RequireLoginMiddleware', ) LOGIN_REQUIRED_URLS = ( r'/payment/(.*)$', r'/accounts/home/(.*)$', r'/accounts/edit-account/(.*)$', ) In a nutshell this requires the user to login for any url that matches against whats listing in LOGIN_REQUIRED_URLS. The system will redirect to [LOGIN_URL](http://www.djangoproject.com/documentation/settings/#login-url)
A handy ANSI-colored logging mechanism to display the SQL queries and times in the terminal when using django-admin.py runserver. DEBUG mode must be true for this to work.
This middleware allows developers to "fake" browser support for HTTP methods. Even though most modern browsers only support GET and POST, the HTTP standard defines others. In the context of REST, PUT and DELETE are used for client interaction with the server. For forms with a PUT or DELETE method, this middleware will change them to go through POST, and will include an invisible field called "method_middleware_transform" that carries the originally intended method. So, `<form method="PUT" ...>...</form>` More or less becomes `<form method="POST" ...><input type=hidden name="method_middleware_transform" value="PUT"></form>` (with a few other minor HTML modifications) The process is completely transparent to the developer... you never have to deal with the fact that browsers don't support the standard methods. **One caveat** is that server interaction via `XMLHttpRequest` (AJAX) requires special attention... this middleware won't properly setup your XMLHttpRequest to take advantage of this functionality. This is a combination of the work of Jesse Lovelace and the Django CSRF middleware.
This is based on a snippet contributed by zbyte64 ( RequireLoginMiddleware) but turned on its head. RequireLoginMiddleware enforces authentication for a subset of urls defined in settings.py. This middleware requires authentication for all urls except those defined in settings.py. The aim is to globally enforce site wide authentication without having to decorate individual views. To use, add the class to MIDDLEWARE_CLASSES and then define the urls you don't need authentication for. These go in a tuple called PUBLIC_URLS in settings.py. For example:- PUBLIC_URLS = ( r'project/application/login/', r'project/application/signup/', ) By default, authentication is not required for any urls served statically by Django. If you want to subject these to the same validation, add an entry to settings.py called SERVE_STATIC_TO_PUBLIC with a value of True.
This is an example middleware that is highly inspired by how Symfony handles [i18n in URLs](http://www.symfony-project.com/book/trunk/13-I18n-and-L10n#Changing the Culture for a User). You basically set a (?P<dj_culture>[\w-]+) pattern in your URL and this middleware will determine the language to use for the i18n toolkit for Django. It also removes the dj_culture parameter after dealing with it, so that you don't have to change all the views you want this middleware to work with.
This middleware will add a log of the SQL queries executed at the bottom of every page. It also includes a query count and total and per-query execution times.
Intall -------- In your settings.py, set it in MIDDLEWARE_CLASSES. Default all the profile files will be save in ./profile folder(if there is no this directory, it'll automatically create one), and you can set a PROFILE_DATA_DIR option in settings.py, so that the profile files can be saved in this folder. How does it works ------------------- Record every request in a profile file. As you can see in the code: profname = "%s.prof" % (request.path.strip("/").replace('/', '.')) so if you request an url multi-times, only the last request will be saved, because previous profile files will be overriden. And you can find a commentted line, it'll save each request in different file according the time, so if you like that you can change the code. # profname = "%s.%.3f.prof" % (request.path.strip("/").replace('/', '.'), time.time()) and if you want to see the output, you can run below code, but you should change the filename value: import hotshot, hotshot.stats stats = hotshot.stats.load(filename) #stats.strip_dirs() #stats.sort_stats('time', 'calls') stats.print_stats()
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.
This Middleware is to log users out after a certain amount of time has passed. You'll want to add AUTO_LOGOUT_DELAY to your settings.py, set to a number of minutes after which a user should be logged out. It adds the key 'last_touch' to the session, you'll want to change that if you happen to be using that already.
Used for showing size of the page in human readable format and time taken to generate the page on the server. To use it, in your base template, somewhere put the line: `<!-- ____SIZE_AND_DATE_PLACEHOLDER____ -->`. May be used on production.
Adds an additional template dir to settings.TEMPLATE_DIRS if the request's HTTP_USER_AGENT string has the word iPhone in it. Allows you to easily create iPhone templates.
A clean and simple implementation of parsing the Accept header. It places the result in request.accepted_types. Place this middleware anywhere in the chain, as all it does is add to the request object.
a minor remix of simon's debug footer: <http://www.djangosnippets.org/snippets/766/> > Adds a hidden footer to the bottom of every text/html page containing a list of SQL queries executed and templates that were loaded (including their full filesystem path to help debug complex template loading scenarios). This version adds TextMate links : if you are working on your local machine and using TextMate you can click on the template paths and they will be opened in TextMate. This speeds up development time considerably ! also, this works with django 1.0 (simon's version got broke by the 'connect' refactor) update: the view function is now linked > To use, drop in to a file called 'debug_middleware.py' on your Python path and add 'debug_middleware.DebugFooter' to your MIDDLEWARE_CLASSES setting.
I needed a quick and dirty way to block a user from my site. Just include this middleware class under the 'MIDDLEWARE_CLASSES' variable in your settings.py file. Also include the variable BLOCKED_IPS = ('123.123.123.123',) variable, where the value is a tuple of IP addresses you want blocked from your site.