Permissions and security

Some notes on gateway & resource protection.

Because we need the REST API to facilitate the same usage patterns as a regular oscar HTML frontend, we need protection of resources on several levels.

  1. Gateway level. An API token can be used to communicate with the REST API. That means we can authorize client applications to make use of the REST API. Examples of client applications are a website or a mobile application. See also the Gateway MiddleWare.
  2. User level. Because we don’t want resource protection to be the responsibility of the client application, we need restrictions of resource access on a user level. The user will use the REST API through an authorized client application. A user must only be able to access his own resources and it must be strictly enforced inside the REST API, that there is no way an API client application can access resources of a different user than the one identified to the REST API. Effectively an authorized client application can only manipulate resources on a user level and not on an administrator level. See aso the main-settings-label.

Anonymous users

Just like the oscar HTML frontend, some part of the functionality of oscar is available to anonymous users. That doesn’t mean an anonymous user can not be identified. They are identified by their session, the same way as in a regular HTML frontend.

There is an upgrade path for an anonymous user, to become an authenticated user, which opens up the functionality restricted to authenticated users.

A client application can upgrade a user by using the login API, See also the Login the user example.

The following actions will be performed when a user logs in:

  1. The user will be authenticated with the REST API. The next steps will only be performed if login is successful.
  2. The anonymous cart will be merged with the private cart associated with that authenticated user.
  3. A new session will be started, this session identifies the authenticated user for the duration of the session.
  4. The new, merged cart will be associated with this session.
  5. The anonymous session will be terminated.
  6. A response will be issued containing the new session id.


The Django REST Framework already supplies it’s own defined permissions to make sure that you can define which user can do what (PUT or just GET etc.). Oscar API is using the following permissions, which you can use in your own views:

class oscarapi.permissions.APIAdminPermission[source]

The permission for all the admin api views. You only get admin api access when: - OSCARAPI_BLOCK_ADMIN_API_ACCESS is false - you are a staff user (is_staff) - you have any of the model permissions needed (view / add / change / delete)

Feel free to customize!

has_permission(request, view)[source]

Return True if permission is granted, False otherwise.

class oscarapi.permissions.IsOwner[source]

Permission that checks if this object has a foreign key pointing to the authenticated user of this request

has_object_permission(request, view, obj)[source]

Return True if permission is granted, False otherwise.

class oscarapi.permissions.RequestAllowsAccessTo[source]
has_object_permission(request, view, obj)[source]

Return True if permission is granted, False otherwise.