Require login across entire site
Middleware that locks down an entire site, requiring the user to login to view any page. Great for development/beta-testing.
- middleware
- authentication
- login
- lockdown
- auth
Snippet List
Profiling Middlware
Displays hotshot profiling for any view. http://yoursite.com/yourview/?prof Add the "prof" key to query string by appending ?prof (or &prof=) and you'll see the profiling results in your browser. It's set up to only be available in django's debug mode, but you really shouldn't add this middleware to any production configuration. * Only tested on Linux * You should probably use this one instead: http://djangosnippets.org/snippets/2126/
- middleware
- profile
- debug
- stats
- performance
- hotshot
SSL Middleware
**SSL Middleware** This middleware answers the problem of redirecting to (and from) a SSL secured path by stating what paths should be secured in urls.py file. To secure a path, add the additional view_kwarg 'SSL':True to the view_kwargs. For example ` urlpatterns = patterns('some_site.some_app.views', (r'^test/secure/$','test_secure',{'SSL':True}), ) ` All paths where 'SSL':False or where the kwarg of 'SSL' is not specified are routed to an unsecure path. For example ` urlpatterns = patterns('some_site.some_app.views', (r'^test/unsecure1/$','test_unsecure',{'SSL':False}), (r'^test/unsecure2/$','test_unsecure'), ) ` **Gotcha's** Redirects should only occur during GETs; this is due to the fact that POST data will get lost in the redirect. **Benefits/Reasoning** A major benefit of this approach is that it allows you to secure django.contrib views and generic views without having to modify the base code or wrapping the view. This method is also better than the two alternative approaches of adding to the settings file or using a decorator. It is better than the tactic of creating a list of paths to secure in the settings file, because you DRY. You are also not forced to consider all paths in a single location. Instead you can address the security of a path in the urls file that it is resolved in. It is better than the tactic of using a @secure or @unsecure decorator, because it prevents decorator build up on your view methods. Having a bunch of decorators makes views cumbersome to read and looks pretty redundant. Also because the all views pass through the middleware you can specify the only secure paths and the remaining paths can be assumed to be unsecure and handled by the middleware. This package is inspired by Antonio Cavedoni's SSL Middleware Notes: Updated per Jay Parlar at http://www.djangosnippets.org/snippets/240/ - Added a test for the way webfaction handles forwarded SSL requests.
- middleware
- ssl
Super User Conditional Page Exception Reporting
**Step 1** Save somewhere in your project directory **Step 2** Add to your settings.py MIDDLEWARE_CLASSES = ( 'django.middleware.common.CommonMiddleware', 'django.contrib.sessions.middleware.SessionMiddleware', 'django.contrib.auth.middleware.AuthenticationMiddleware', 'django.middleware.doc.XViewMiddleware', 'utils.debug.UserBasedExceptionMiddleware', ) Normal users will get your 500.html when debug = False, but If you are logged in as a super user then you get to see the stack trace in all its glory.
- middleware
- debug
- exception
DebugFooter middleware
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). 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.
- sql
- middleware
- debugging
Simple Exception Response for AJAX debugging
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).
- middleware
- ajax
- exception-handling
Middleware to detect visitors who arrived from a search engine
Sometimes it's nice to know if your visitors came from a search engine such as Google or Yahoo. I use this as a component in determining the popularity of blog articles for search keywords, so I know which articles to automatically feature or suggest. Maybe you'd like to use it to highlight the visitor's search terms on the page. This isn't actually middleware in the sense that it defines any of the middleware interfaces. It's intended to be the base for a middleware method that you write, depending on what you want to happen when you detect that the visitor came from a search engine. In the example `process_view` method, I detect when the request is going to use the `object_detail` view and log the search query for that object in the database.
- middleware
- search-engine
- referrer
AdminPeepingMiddleware
Peeping middleware, that replaces active user to another one for current http request. Admin permissions required to activate, so you can place this snippet even on the production server. Very useful for debugging purposes. Wish it to be part of Django. How to use: Put this middleware after all other middlewares in the list. Then just add ?as_user=username or &as_user=username to the url, where username is the name of user whose views you want to see.
- middleware
- admin
- view
- permissions
- peep
Profiling middleware using cProfile
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.
- middleware
- performance
- profiler
Extended Profiling Middleware
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.
- middleware
- profile
- hotshot
SQL Log Middleware w/query count & exec time
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.
- sql
- middleware
- log
Subdomain Middleware
This snippet will add the subdomain and domain to the request object for use in your views.
- middleware
- subdomain
Debug Page Load Time Stats Middleware
Use this to display a split of page execution time between python and the db in your base template when debugging. I originally got the base of this code from another snippet, but I can't find it anymore and want to share with new folks because I find this handy.
- middleware
- profile
- time
- debug
- performance
- query
- basetemplate
SQL Printing Middleware
Just put it in your python path and add it into MIDDLEWARE_CLASSES. I know that there are a couple of snippets on this site that do something similar to this, but none of them quite suited me. I wanted something that would indent and space the SQL so that I could differentiate it from the other output from the development server. Also, I wanted something that would output total query execution time, which my solution does. I just hope that it's useful for someone else, too! UPDATE: Now this should no longer get upset when running it on windows.
- sql
- middleware
- profile
- debug
- help
- console
- printing
- speed
Notifications Middleware for Session-Backed Messages
simple middleware and context processor for session-based messaging with types Heavily inspired by patches on ticket 4604. Differs in that in this a notification has type. Installation: * add notifications.NotificationMiddleware to MIDDLEWARE_CLASSES * and notifications.notifications to TEMPLATE_CONTEXT_PROCESSORS That assumes notifications.py is on pythonpath. If notifications.py lives in your project dir, prefix those with '(projectname).' Example use: * request.notifications.create('Some bland information message.') * request.notifications.create('Some more exciting error message.', 'error') Example template code: `{% if notifications %} <ul id="notifications"> {% for notification in notifications %}<li class="{{ notification.type }}">{{ notification.content }}</li> {% endfor %} </ul> {% endif %}` [rendered example](http://traviscline.com/blog/2008/08/23/django-middleware-session-backed-messaging/)
- middleware
- flash
- notifications