Views code and details

Generic

Generic views are intended to use in a “batteries included” fashion to protect own views with OAuth2 authentication and Scopes handling.

class oauth2_provider.views.generic.ProtectedResourceView(**kwargs)

Generic view protecting resources by providing OAuth2 authentication out of the box

server_class

alias of Server

class oauth2_provider.views.generic.ReadWriteScopedResourceView(**kwargs)

Generic view protecting resources with OAuth2 authentication and read/write scopes. GET, HEAD, OPTIONS http methods require “read” scope. Otherwise “write” scope is required.

class oauth2_provider.views.generic.ScopedProtectedResourceView(**kwargs)

Generic view protecting resources by providing OAuth2 authentication and Scopes handling out of the box

Mixins

These views are mainly for internal use, but advanced users may use them as basic components to customize OAuth2 logic inside their Django applications.

class oauth2_provider.views.mixins.OAuthLibMixin

This mixin decouples Django OAuth Toolkit from OAuthLib.

Users can configure the Server, Validator and OAuthlibCore classes used by this mixin by setting the following class variables:

  • server_class
  • validator_class
  • oauthlib_core_class # TODO rename it as oauthlib_backend_class
create_authorization_response(request, scopes, credentials, allow)

A wrapper method that calls create_authorization_response on server_class instance.

Parameters:
  • request – The current django.http.HttpRequest object
  • scopes – A space-separated string of provided scopes
  • credentials – Authorization credentials dictionary containing client_id, state, redirect_uri, response_type
  • allow – True if the user authorize the client, otherwise False
create_token_response(request)

A wrapper method that calls create_token_response on server_class instance.

Parameters:request – The current django.http.HttpRequest object
error_response(error, **kwargs)

Return an error to be displayed to the resource owner if anything goes awry.

Parameters:errorOAuthToolkitError
classmethod get_oauthlib_core()

Cache and return OAuthlibCore instance so it will be created only on first request

classmethod get_oauthlib_core_class()

Return the OAuthLibCore implementation class to use, silently defaults to OAuthLibCore class from oauth2_provider package

# TODO rename this as get_oauthlib_backend_class

get_scopes()

This should return the list of scopes required to access the resources. By default it returns an empty list

classmethod get_server()

Return an instance of server_class initialized with a validator_class object

classmethod get_server_class()

Return the OAuthlib server class to use

classmethod get_validator_class()

Return the RequestValidator implementation class to use

validate_authorization_request(request)

A wrapper method that calls validate_authorization_request on server_class instance.

Parameters:request – The current django.http.HttpRequest object
verify_request(request)

A wrapper method that calls verify_request on server_class instance.

Parameters:request – The current django.http.HttpRequest object
class oauth2_provider.views.mixins.ProtectedResourceMixin

Helper mixin that implements OAuth2 protection on request dispatch, specially useful for Django Generic Views

class oauth2_provider.views.mixins.ReadWriteScopedResourceMixin

Helper mixin that implements “read and write scopes” behavior

class oauth2_provider.views.mixins.ScopedResourceMixin

Helper mixin that implements “scopes handling” behaviour

get_scopes(*args, **kwargs)

Return the scopes needed to access the resource

Parameters:args – Support scopes injections from the outside (not yet implemented)

Base

Views needed to implement the main OAuth2 authorization flows supported by Django OAuth Toolkit.

class oauth2_provider.views.base.AuthorizationView(**kwargs)

Implements and endpoint to handle Authorization Requests as in RFC6749 Section 4.1.1 and prompting the user with a form to determine if she authorizes the client application to access her data. This endpoint is reached two times during the authorization process: * first receive a GET request from user asking authorization for a certain client application, a form is served possibly showing some useful info and prompting for authorize/do not authorize.

  • then receive a POST request possibly after user authorized the access

Some informations contained in the GET request and needed to create a Grant token during the POST request would be lost between the two steps above, so they are temporary stored in hidden fields on the form. A possible alternative could be keeping such informations in the session.

The endpoint is used in the followin flows: * Authorization code * Implicit grant

server_class

alias of Server

class oauth2_provider.views.base.BaseAuthorizationView(**kwargs)

Implements a generic endpoint to handle Authorization Requests as in RFC6749 Section 4.1.1. The view does not implement any strategy to determine authorize/do not authorize logic. The endpoint is used in the following flows:

  • Authorization code
  • Implicit grant
error_response(error, **kwargs)

Handle errors either by redirecting to redirect_uri with a json in the body containing error details or providing an error response

class oauth2_provider.views.base.TokenView(**kwargs)

Implements an endpoint to provide access tokens

The endpoint is used in the following flows: * Authorization code * Password * Client credentials

server_class

alias of Server