Login

Tag "request"

30 snippets

Snippet List

Get the referer view of a request

Get the referer view of a request. **Example:** def some_view(request): ... referer_view = get_referer_view(request) return HttpResponseRedirect(referer_view, '/accounts/login/')

  • view
  • referer
  • request
  • path
Read More

another request logging middleware with request time and extra info

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

  • middleware
  • request-path
  • time
  • request
  • logging
  • time-logging
Read More

Add GET parameters from current request

The tag generates a parameter string in form '?param1=val1&param2=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

  • get
  • request
  • parameters
  • add
Read More

Inject request into functions

Long story short: * Django lets you call functions in templates, but you can't pass any parameters. * Sometimes you need to use the request object to perform certain tasks, such as determining whether the current user has permission to do something. * The recommended approach is to call functions that require parameters in the view, and then pass the results as variables in the context. This sometimes feels a bit overkill. * Creating a templatetag to call any function with any parameter will definitely break the intention for not letting functions to be called with parameters in templates. * So, what if we could tell django to inject the request into certain functions? That's what this decorator is for. For instance, suppose you have a model: class SomeModel(models.Model): ... def current_user_can_do_something(self, request): ...some logic here using request... You could use the decorator like this: class SomeModel(models.Model): ... @inject_request def current_user_can_do_something(self, request=None): ...some logic here using request... And in the template go straight to: {{ somemodel_instance.current_user_can_do_something }} So that the decorator would perform some operations to find the request in the frame tree and inject it if found. The assertions are intented to make sure things will work even if the request cannot be found, so that the coder may program defensively.

  • templates
  • request
  • decorators
Read More

Decorator to limit request rates to individual views

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).

  • request
  • rate
  • limit
Read More

Add get_addr() method to 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`.

  • request
  • ip
  • header
  • address
  • client
  • remote-addr
  • x-forwarded-for
  • get-addr
Read More

Append paramaters to a GET querystring (template tag)

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.

  • get
  • pagination
  • request
Read More

Get Client IP Behind Proxy

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).

  • request
  • ip
Read More

Add Extra Headers to Test Client Requests

As Simon Willison mentions in his [Debugging Django](http://simonwillison.net/2008/May/22/debugging/) presentation, using the Test Client in the interpreter can be a great way to take a peek at the raw results from a view. In some cases you may need to add additional headers to the request (for instance a piece of middleware may rely on them). Though it is not mentioned in the reference documentation, a quick peek at the code confirmed my hopes that it would be possible to add data to the request. The Client *get* and *post* methods both accept an **extra** kwargs parameter that allow you to populate the request with additional data.

  • testing
  • request
  • test
  • headers
Read More

Add querystring parameters to path (template tag)

`<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 %}&laquo; Previous {% if page.has_previous %}</a>{% endif %} | {% if page.has_next %} <a href="{% url_add_query page=page.next_page_number %}">{% endif %} Next &raquo;{% if page.has_next %}</a>{% endif %} </div> {% endif %}`

  • template
  • templatetag
  • pagination
  • request
  • querystring
  • query-string
Read More

create_c

Instead of creating a dictionary on every view everytime you could do this and just call it like c = create_c(request)

  • templates
  • request
  • data
  • csrf
Read More