namespaces The list of individual namespace components in the full instance namespace for the URL pattern that matches the URL. i.e., if the namespace is foo:bar, then namespaces will be ['foo', 'bar'].

url_name The name of the URL pattern that matches the URL.

view_name The name of the view that matches the URL, including the namespace if there is one.

reverse(viewname, urlconf=None, args=None, kwargs=None, current_app=None) [source] viewname can be a URL pattern name or the callable view object. For example, given the following url: from news import views url(r'^archive/$', views.archive, name='news-archive') you can use any of the following to reverse the URL: # using the named URL reverse('news-archive') # passing a callable object # (This is discouraged because you can't reverse namespaced views this way.) from news import views rev

reverse_lazy(viewname, urlconf=None, args=None, kwargs=None, current_app=None) It is useful for when you need to use a URL reversal before your project’s URLConf is loaded. Some common cases where this function is necessary are: providing a reversed URL as the url attribute of a generic class-based view. providing a reversed URL to a decorator (such as the login_url argument for the django.contrib.auth.decorators.permission_required() decorator). providing a reversed URL as a default value f

Django comes with a user authentication system. It handles user accounts, groups, permissions and cookie-based user sessions. This section of the documentation explains how the default implementation works out of the box, as well as how to extend and customize it to suit your project’s needs. Overview The Django authentication system handles both authentication and authorization. Briefly, authentication verifies a user is who they claim to be, and authorization determines what an authenticated

Introductions to all the key parts of Django you’ll need to know: How to install Django Models and databases Handling HTTP requests Working with forms Templates Class-based views Migrations Managing files Testing in Django User authentication in Django Django’s cache framework Conditional View Processing Cryptographic signing Sending email Internationalization and localization Logging Pagination Porting to Python 3 Security in Django Performance and optimization Serializing Django objects Djang

Caution This is an advanced topic. A working knowledge of Django’s class-based views is advised before exploring these techniques. Django’s built-in class-based views provide a lot of functionality, but some of it you may want to use separately. For instance, you may want to write a view that renders a template to make the HTTP response, but you can’t use TemplateView; perhaps you need to render a template only on POST, with GET doing something else entirely. While you could use TemplateRespo

add_never_cache_headers(response) [source] Adds a Cache-Control: max-age=0, no-cache, no-store, must-revalidate header to a response to indicate that a page should never be cached. Changed in Django 1.8.8: In older versions, Cache-Control: max-age=0 was sent. This didn’t reliably prevent caching in all browsers.

get_cache_key(request, key_prefix=None) [source] Returns a cache key based on the request path. It can be used in the request phase because it pulls the list of headers to take into account from the global path registry and uses those to build a cache key to check against. If there is no headerlist stored, the page needs to be rebuilt, so this function returns None.