Templates

A set of templates is provided. These templates range from Django Admin Site alternatives to manage the Apps that use your App as a provider, to Error and Authorization Templates.

You can override default templates located in templates/oauth2_provider folder and provide a custom layout. To override these templates you just need to create a folder named oauth2_provider inside your templates folder and, inside this folder, add a file that matches the name of the template you’re trying to override.

The templates available are:

base.html

If you just want a different look and feel you may only override this template. To inherit this template just add {% extends "oauth2_provider/base.html" %} in the first line of the other templates. This is what is done with the default templates.

The blocks defined in it are:

  • title inside the HTML title tag;

  • css inside the head;

  • content in the body.

Default stylesheet

The css block loads a small stylesheet that ships with the package, from static/oauth2_provider/css/oauth2_provider.css:

{% block css %}
    <link href="{% static 'oauth2_provider/css/oauth2_provider.css' %}" rel="stylesheet">
{% endblock css %}

It is served like any other static file, so run collectstatic (or serve the app’s static files some other way) for the built-in pages to be styled. Because nothing is fetched from a third-party host and no inline <style> is used, the shipped pages render offline and under a strict Content Security Policy such as default-src 'self' (see Content Security Policy and the authorization form).

To use your own styles — a CSS framework, or your site’s stylesheet — override the css block:

{% extends "oauth2_provider/base.html" %}
{% load static %}

{% block css %}
    <link href="{% static 'my_project/css/oauth2.css' %}" rel="stylesheet">
{% endblock css %}

The shipped templates use these class names, which a replacement stylesheet needs to cover: container, block-center, block-center-heading, unstyled, control-group (plus error), control-label, controls, form-horizontal, input-block-level, help-block, help-inline, btn, btn-large, btn-primary, btn-danger, btn-success and btn-toolbar. They are the Bootstrap 2 names the templates have always used, so a Bootstrap-based override keeps working.

authorize.html

Authorize is rendered in AuthorizationView (authorize/).

This template gets passed the following context variables:

  • scopes - list with the scopes requested by the application;

Caution

See DEFAULT_SCOPES to understand what is returned if no scopes are requested.

  • scopes_descriptions - list with the descriptions for the scopes requested;

  • application - An Application object

Note

If you haven’t created your own Application Model (see how in Extending the Application model), you will get an AbstractApplication object.

  • client_id - Passed in the URI, already validated.

  • redirect_uri - Passed in the URI (optional), already validated.

Note

If it wasn’t provided on the request, the default one has been set (see default_redirect_uri()).

  • response_type - Passed in the URI, already validated.

  • state - Passed in the URI (optional).

  • form - An AllowForm with all the hidden fields already filled with the values above.

Important

One extra variable, named error will also be available if an Oauth2 exception occurs. This variable is a dict with error and description

Example (this is the default page you may find on templates/oauth2_provider/authorize.html):

{% extends "oauth2_provider/base.html" %}

{% load i18n %}
{% block content %}
    <div class="block-center">
        {% if not error %}
            <form id="authorizationForm" method="post">
                <h3 class="block-center-heading">{% trans "Authorize" %} {{ application.name }}?</h3>
                {% csrf_token %}

                {% for field in form %}
                    {% if field.is_hidden %}
                        {{ field }}
                    {% endif %}
                {% endfor %}

                <p>{% trans "Application requires the following permissions" %}</p>
                <ul>
                    {% for scope in scopes_descriptions %}
                        <li>{{ scope }}</li>
                    {% endfor %}
                </ul>

                {{ form.errors }}
                {{ form.non_field_errors }}

                <div class="control-group">
                    <div class="controls">
                        <input type="submit" class="btn btn-large" value="Cancel"/>
                        <input type="submit" class="btn btn-large btn-primary" name="allow" value="Authorize"/>
                    </div>
                </div>
            </form>

        {% else %}
            <h2>Error: {{ error.error }}</h2>
            <p>{{ error.description }}</p>
        {% endif %}
    </div>
{% endblock %}

Management

The management templates are Django Admin Site alternatives to manage the Apps.

All templates receive Application objects.

Note

If you haven’t created your own Application Model (see how in Extending the Application model), you will get an AbstractApplication object.

application_list.html

Rendered in ApplicationList (applications/). This class inherits django.views.generic.edit.ListView.

This template gets passed the following template context variable:

  • applications - a list with all the applications, may be None.

application_form.html

Rendered in ApplicationUpdate (applications/<pk>/update/). This class inherits django.views.generic.edit.UpdateView.

This template gets passed the following template context variables:

  • application - the Application object.

  • form - a Form with the following fields:

    • name

    • client_id

    • client_secret

    • client_type

    • authorization_grant_type

    • redirect_uris

    • post_logout_redirect_uris

Caution

In the default implementation this template in extended by application_registration_form.html. Be sure to provide the same blocks if you are only overriding this template.

Note

Application validation errors are attached to the field they belong to (for example a rejected redirect URI to redirect_uris, or a non-https CORS origin to allowed_origins), so a custom template should render field.errors for every field as the shipped one does. Keep rendering form.non_field_errors as well: an error for a field the form does not include falls back to a non-field error.

application_registration_form.html

Rendered in ApplicationRegistration (applications/register/). This class inherits django.views.generic.edit.CreateView.

This template gets passed the following template context variable:

  • form - a Form with the following fields:

    • name

    • client_id

    • client_secret

    • client_type

    • authorization_grant_type

    • redirect_uris

    • post_logout_redirect_uris

Note

In the default implementation this template extends application_form.html.

application_detail.html

Rendered in ApplicationDetail (applications/<pk>/). This class inherits django.views.generic.edit.DetailView.

This template gets passed the following template context variable:

application_confirm_delete.html

Rendered in ApplicationDelete (applications/<pk>/delete/). This class inherits django.views.generic.edit.DeleteView.

This template gets passed the following template context variable:

Important

To override successfully this template you should provide a form that posts to the same URL, example: <form method="post" action="">

Token

All templates receive AccessToken objects.

authorized-tokens.html

Rendered in AuthorizedTokensListView (authorized_tokens/). This class inherits django.views.generic.edit.ListView.

This template gets passed the following template context variable:

  • authorized_tokens - a list with all the tokens that belong to applications that the user owns, may be None.

Important

To override successfully this template you should provide links to revoke the token, example: <a href="{% url 'oauth2_provider:authorized-token-delete' authorized_token.pk %}">revoke</a>

authorized-token-delete.html

Rendered in AuthorizedTokenDeleteView (authorized_tokens/<pk>/delete/). This class inherits django.views.generic.edit.DeleteView.

This template gets passed the following template context variable:

Important

To override successfully this template you should provide a form that posts to the same URL, example: <form method="post" action="">