Currently, Authorizer.validate requires all AccessRange objects to exist in db, even though it doesn't actually use them anywhere, which creates a problem in the following scenario:
Client asks to authorize access to "public/images:rw public/docs:rw private:rw", making a GET request.
Request is parsed and User is presented a POST form, asking his/her approval for each access_range in scope.
User denies "private:rw" access, so OAuth2 should return reduced scope ("public/images:rw public/docs:rw") to the Client.
Authorizer.validate has to be called, validating same GET parameters and demanding AccessRange "private:rw" to exist, even though it will not be used in any way.
Authorizer.scope gets updated (with allowed ranges) and Authorizer.grant_redirect is called, providing access_token to the Client.
There are workarounds for this, including temporary creating "private:rw" AccessRange, redirect to change GET parameters or just ignore InvalidScope error, neither of which seem to be particulary good and supported.
I'm also unsure if updating Authorizer.scope is the supported way to return reduced access_ranges.
If not, I propose adding a "scope" parameter to Authorizer.grant_redirect method, to facilitate such use-case (partial authorization).
Related to the same use-case as #31.
Currently,
Authorizer.validaterequires allAccessRangeobjects to exist in db, even though it doesn't actually use them anywhere, which creates a problem in the following scenario:Authorizer.validatehas to be called, validating same GET parameters and demandingAccessRange"private:rw" to exist, even though it will not be used in any way.Authorizer.scopegets updated (with allowed ranges) andAuthorizer.grant_redirectis called, providing access_token to the Client.There are workarounds for this, including temporary creating "private:rw"
AccessRange, redirect to change GET parameters or just ignoreInvalidScopeerror, neither of which seem to be particulary good and supported.I'm also unsure if updating
Authorizer.scopeis the supported way to return reduced access_ranges. If not, I propose adding a "scope" parameter toAuthorizer.grant_redirectmethod, to facilitate such use-case (partial authorization).