Testing (and mocking) http requests to APIs etc.
You can test how your django app behaves depending on what kind of response it gets from the API. It assumes were're using the python requests library.
- http
- testing
- requests
- mock
You can test how your django app behaves depending on what kind of response it gets from the API. It assumes were're using the python requests library.
This allows the mod_xsendfile module for Apache safely serving private files. Django take cake about processing and permissions checking, Apache server requested files. Installation of mod_xsendfile: $ tar -xzvf mod_xsendfile-0.12.tar.gz $ /usr/sbin/apxs -c mod_xsendfile-0.12/mod_xsendfile.c $ ld -Bshareable -o mod_xsendfile-0.12/mod_xsendfile.so mod_xsendfile-0.12/mod_xsendfile.o Copy mod_xsendfile.so to your local Apache modules folder. Modify httpd.conf to load an enable the module: LoadModule xsendfile_module modules/mod_xsendfile.so Add to virtual host container: <Virtual ...:80> XSendFile On XSendFilePath /home/django_projects/mysite/media/ </Virtual>
Decorator adding arbitrary HTTP headers to the response. This decorator adds HTTP headers specified in the argument (map), to the HTTPResponse returned by the function being decorated. Example: @headers({'Refresh': '10', 'X-Bender': 'Bite my shiny, metal ass!'}) def index(request): ....
Calls a view by request.method value. To use this dispatcher write your urls.py like this: urlpatterns = pattern('', url(r'^foo/$', dispatch(head=callable1, get=callable2, delete=callable3)), ) If `request.method` is equal to head, `callable1` will be called as your usual view function; if it is `get`, `callable2` will be called; et cetera. If the method specified in request.method is not one handled by `dispatch(..)`, `HttpResponseNotAllowed` is returned.
Adds an 'X-Django-Request-Time' HTTP response header that times how long django spent processing the request.
In the same vein as [snippet 436](http://www.djangosnippets.org/snippets/436/), this allows you to differentiate view logic by HTTP method such as GET, POST, PUT, DELETE. This is also very useful combined with the [HttpMethodsMiddleware snippet](http://www.djangosnippets.org/snippets/174/). I am not the author, but I have found it to be very helpful.
Yet another implementation of class based RESTful dispatch. This particular implementation features: * You do not have to call __init__ from the derived classes. * Avoids __metaclass__ which (in our environment) led to unexpected method override behavior. * Method names match the google webapp API. * One new instance per request to reduce errors in multi-threaded code. Snippets of inspiration: * [436](http://www.djangosnippets.org/snippets/436/) * [437](http://www.djangosnippets.org/snippets/437/) * [1071](http://www.djangosnippets.org/snippets/1071/) * [1072](http://www.djangosnippets.org/snippets/1072/) * [1226](http://www.djangosnippets.org/snippets/1226/)
This generic view does the same that 'django.views.generic.simple.redirect_to' does but supports request.GET parameters.
When you neeed to do redirect and request object is not available, you can do it with exception. Put exception handler somewhere request is available, for example to middleware or ModelAdmin. Raise exception, where request is not available.
Allows url patterns to include a boolean indicating whether a view requires TLS(SSL). The accompanying middleware handles the redirects needed to make sure that it upholds this requirement. **WARNING**: this monkey-patches some Django internals and is difficult to test since Django's TestClient does not support TLS. If you use this make sure you test it thouroughly. Add this to your Django settings USE_TLS = True # The default for this setting is False. URL pattern usage url(r'^login$', 'myproject.login.index', {'require_tls': True}, name='login-index'), Use `require_tls` True to force the middleware to perform redirects needed to make sure your are serving this view using https. Use `require_tls` False to force the middleware to redirect to http. Be careful with this setting, this may not behave as you expect. If you don't care if the view is served via https or http then do not include `require_tls` in the pattern. If you wish to have every view in the site served with TLS then specify the following Django setting ALWAYS_USE_TLS = True # Django setting, use TLS for every view
Two middlewares to handle languages via HTTP GET original code by stefan reinhard, check against django.conf.settings by me
Subclass `Resource` to create a view that will dispatch based on the HTTP method of the request. class View(Request): def DELETE(self, request): ... def GET(self, request): ... def PUT(self, request): ... Other snippets provided inspiration: * [436](http://www.djangosnippets.org/snippets/436/) * [437](http://www.djangosnippets.org/snippets/437/) * [1071](http://www.djangosnippets.org/snippets/1071/) * [1072](http://www.djangosnippets.org/snippets/1072/) The code is also available on [GitHub](http://github.com/jpwatts/django-restviews/).
This snippet for Piston allows you to offer a choice of authentication methods to clients.
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).
Sometimes, when views are particularly complex, it's useful to send the different request methods to different functions. If you have to do this frequently, the repetition gets tiring. This helper class can be used to simplify that.