notes
or notes.readonly
. When a client application authenticates on behalf of a user, it requests one or more of these scope identifiers to be granted to the access token. Valid scopes will be stored with the access token, so that the scope can be referenced by subsequent uses of the access token.Authorizer
retrieves the token's scope. After the request is validated, the Authorizer
stores scope information in Request.authorization
. Linked controllers can use this information to determine how the request is handled. In general, a controller will reject a request and send a 403 Forbidden response when an access token has insufficient scope for an operation.Authorizer
handles a request, it creates an Authorization
object that is attached to the request. An Authorization
object has a scopes
property that contains every scope granted for the access token. This object also has a convenience method for checking if a particular scope is valid for that list of scopes:authorization
property of Request
is only valid after the request is handled by an Authorizer
. It is null
otherwise.Authorizer
may also validate the scope of a request before letting it pass to its linked controller.NoteController
will only be reached if the request's bearer token has 'notes' scope. If there is insufficient scope, a 403 Forbidden response is sent. This applies to all operations of the NoteController
.Scope
annotation may be added to ResourceController
operation methods for this purpose.Scope
annotations, you must link an Authorizer
prior to the ResourceController
, but it is not necessary to specify Authorizer
scopes.Scope
annotation or Authorizer
contains multiple scope entries, an access token must have scope for each of those entries. For example, the annotation @Scope(['notes', 'user'])
requires an access token to have both 'notes' and 'user' scope.conduit auth
command-line tool. When creating a new client identifier, include the --allowed-scopes
options:conduit auth set-scope
:com.app.mobile
client ID to grant access tokens with 'notes' and 'users' scope. If a client application requests scopes that are not available for that client application, the granted access token will not contain that scope. If none of the request scopes are available for the client identifier, no access token is granted. When adding scope restrictions to your application, you must ensure that all of the client applications that have access to those operations are able to grant that scope.getAllowedScopes
in AuthServerDelegate
. By default, this method returns AuthScope.Any
- which means there are no restrictions. If the client application allows the scope, then any user that logs in with that application can request that scope.AuthScope
s that are valid for the authenticating user. The following example shows a ManagedAuthDelegate<T>
subclass that allows any scope for @conduit.dart.com
usernames, no scopes for @hotmail.com
addresses and some limited scope for everyone else:user
passed to getAllowedScopes
is the user being authenticated. It will have previously been fetched by the AuthServer
. The AuthServer
fetches this object by invoking AuthDelegate.getResourceOwner
. The default implementation of this method for ManagedAuthDelegate<T>
only fetches the id
, username
, salt
and hashedPassword
of the user.getResourceOwner
to fetch these attributes. For example, if your application's user has a role
attribute, you must fetch it and the other four required properties. Here's an example implementation:AuthController
, a scope
parameter must be added to the form data body. This parameter's value must be a space-delimited, URL-encoded list of requested scopes.AuthCodeController
, this same query parameter is added to the initial GET
request to render the login form.:
and .
.:
character. For example, the following is a hierarchy of scopes related to a user and its sub-resources:user
(can read/write everything a user has)user:email
(can read/write a user's email)user:documents
(can read/write a user's documents)user:documents:spreadsheets
(can read/write a user's spreadsheet documents)user:email
scope, it only allows access to a user's email. However, if the access token has user
scope, it allows access to everything a user has, including their email.user:documents
scope can access all of a user's documents, but the scope user:documents:spreadsheets
is limited to only spreadsheet documents.user:email:read
and user:email:write
. However, an access token with user:email:write
does not have permission to read email and this is likely unintended..
at the end of a scope string. For example, user:email.readonly
grants readonly access to a user's email whereas user:email
grants read and write access.user
and user:email
can both access user:email.readonly
protected resources and actions, but user:email.readonly
cannot access resources protected by user:email
.user:documents.readonly:spreadsheets
is not valid, but user:documents:spreadsheets.readonly
is.