Ignore scopes passed along with unscoped developer keys?

[cycomachead]

Summary:

I'm working on an app with users across multiple Canvas instances. Some are using new scoped Dev keys, but most are still using unscoped keys. Right now, sending any scopes for along with an app id that is using an unscoped key leads to an error.

Steps to reproduce:

1. Create an unscoped developer key
2. make an oauth request with scopes='...' (any scope will do).

Expected behavior:

Canvas should ignore the scopes in the request since they seem irrelevant.

Actual behavior:

Canvas sends down a 422 error code, and a bunch of html.

Additional notes:

[UniversalSuperBox]

As mentioned in https://github.com/ucfopen/lti-template-flask-oauth-tokens/pull/6, this actually seems to be a combination of two problems:

1. Scope enforcement is turned off
2. A requested scope was malformed or does not exist

In my beta and test instances, meeting both of these was the only way I could get the 422 error you described. If "Enforce scopes" is disabled but I send only the scope url:GET|/api/v1/users/:user_id/profile, I am allowed to create the token. If I then add a new scope, "stuff", to the list and try again, I get the 422 error after clicking "Authorize" in the Canvas authorization prompt.

If I subsequently turn on "Enforce scopes", I instead get {"error":"invalid_scope","error_description":"A requested scope is invalid, unknown, malformed, or exceeds the scope granted by the resource owner."} where the Canvas authorization page should go.

So, I believe Canvas supports getting scoped tokens using an unscoped developer key (indeed, when requesting a token with valid scopes, I get an appropriately scoped token), but the error handling is different whether scope enforcement is toggled on or off.

[rivernate]

sorry wrong issue

[stale[bot]]

Thanks for contributing to this issue. As it has been 2 years since the last activity, we are automatically closing the issue in 30 days. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please respond before the issue is closed, or post a message on the mailing list. We'll gladly take a look again!