Simply adds an attribute `is_ajax` to a request object, indicating if the request was made via Ajax. Allows you to reuse a lot of POST processing view code to which you'd like to progressively add Ajax: `if request.is_ajax: return JsonResponse(some_json)` `else: return render_to_response('some_template.html')`
Example: @limit("global", 3, 10, per_ip=True) def view(request, ...): The example limits the view to one request every 3 seconds per ip address. The limit is shared by every view that uses the string "global" (first parameter), which is an arbitrary string. Request succeed until the accumulated requested time in seconds (second parameter) exceeds the limit (third parameter).
Here are a couple of Django decorators for limiting access to a view based on the request's `HTTP_REFERER`. Both raise a Django `PermissionDenied` exception if the referer test fails (or a referer simply isn't provided). The first, `referer_matches_hostname`, takes a hostname (and port, if specified) and matches it against the referer's. If multiple arguments are supplied a match against any of the hostnames will be considered valid. The second, `referer_matches_re`, takes a regex pattern (like Django's urlpattern) and tests if it matches the referer. This is obviously more flexible than `referer_matches_hostname` providing the ability to match not just the hostname, but any part of the referer url. Finally there's an simple example decorator, `local_referer_only`, that limits a view to the current site by using Django's `django.contrib.sites` to look up the current hostname.
`<h3>Page: {{ page.number }} of {{ page.paginator.num_pages }}</h3> {% if page.has_previous or page.has_next %} <div> {% if page.has_previous %} <a href="{% url_add_query page=page.previous_page_number %}">{% endif %}« Previous {% if page.has_previous %}</a>{% endif %} | {% if page.has_next %} <a href="{% url_add_query page=page.next_page_number %}">{% endif %} Next »{% if page.has_next %}</a>{% endif %} </div> {% endif %}`
This tag is designed to facilitate pagination in the case where both the page number and other parameters (eg. search criteria) are passed via GET. It takes one argument - a dictionary of GET variables to be added to the current url Example usage: {% for page_num in results.paginator.page_range %} <a href="{% append_to_get p=page_num %}">{{ page_num }}</a> {% endfor %} Note that the passed arguments are evaluated within the template context.
The django_admin_log only logs changes, not simple requests. Sometimes it can be useful to log when a user of your admin interface is checking out important data, for instance if you are making a system with personal sensitive data, that needs to comply with government / company policies. This will log such hits to the django_admin_log by overriding the change_view method in ModelAdmin. So you must override this method in all classes you want to have logged.
If your application server is behind a proxy, `request.META["REMOTE_ADDR"]` will likely return the proxy server's IP, not the client's IP. The proxy server will usually provide the client's IP in the `HTTP_X_FORWARDED_FOR` header. This util function checks both headers. I use it behind Amazon's Elastic Load Balancer (ELB).
The tag generates a parameter string in form '?param1=val1¶m2=val2'. The parameter list is generated by taking all parameters from current request.GET and optionally overriding them by providing parameters to the tag. This is a cleaned up version of http://djangosnippets.org/snippets/2105/. It solves a couple of issues, namely: * parameters are optional * parameters can have values from request, e.g. request.GET.foo * native parsing methods are used for better compatibility and readability * shorter tag name Usage: place this code in your appdir/templatetags/add_get_parameter.py In template: {% load add_get_parameter %} <a href="{% add_get param1='const' param2=variable_in_context %}"> Link with modified params </a> It's required that you have 'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS
This is an update to Simon Willison's snippet http://djangosnippets.org/snippets/963/, along with one of the comments in that snippet. This class lets you create a Request object that's gone through all the middleware. Suitable for unit testing when you need to modify something on the request directly, or pass in a mock object. (note: see http://labix.org/mocker for details on how to mock requests for testing) Example on how to use: from django.test import TestCase from yourapp import your_view from yourutils import RequestFactory class YourTestClass(TestCase): def setUp(self): pass def tearDown(self): pass # Create your own request, which you can modify, instead of using self.client. def test_your_view(self): # Create your request object rf = RequestFactory() request = rf.get('/your-url-here/') # ... modify the request to your liking ... response = your_view(request) self.assertEqual(response.status_code, 200) Suggestions/improvements are welcome. :)
This template tag attempts to get specific GET variables from request.GET. If such variables exist, it shows them as a query string (with optional "include_ampersand" mode when it puts an "&" at the end if there is a result string, or a "?" if there's none: it is used when you need to add a new variable to the query string) or as hidden input fields ("html_form" mode).
This is how you can access the user's request in the Form or FormSet definition, e.g. to define the choices of a ChoiceField dynamically. Either you use it for a single Form or a whole FormSet, just pass the view's request into the Form or FormSet instantiation.
Get the referer view of a request. **Example:** def some_view(request): ... referer_view = get_referer_view(request) return HttpResponseRedirect(referer_view, '/accounts/login/')
This is exacly the same snippet as #197 http://www.djangosnippets.org/snippets/197/ but returning search enigne, search engine domain and search term in: request.search_referrer_engine request.search_referrer_domain request.search_referrer_term I wanted to show ads only to people comming from search engines so I took snippet #197 and modify it to put that info in the request object.
I thought it would be useful to have a `get_addr()` method available on request objects, similar to the `get_host()` provided by Django. This middleware will add a `get_addr()` method to requests which uses the `X-Forwarded-For` header (useful if you're behind a proxy) if it's present and you have the `USE_X_FORWARDED_FOR` header set to `True` (default is `False`) and otherwise will use the `REMOTE_ADDR` environment variable. Note that if you are *not* behind a proxy and have `USE_X_FORWARDED_FOR` set to `True`, then clients can spoof their IP by simply setting the `X-Forwarded-For header`.
Simple logging middleware that captures the following: * remote address (whether proxied or direct) * if authenticated, then user email address * request method (GET/POST etc) * request full path * response status code (200, 404 etc) * content length * request process time * If DEBUG=True, also logs SQL query information - number of queries and how long they took