![]() fixes RECNVS-471 fixes RECNVS-479 allows API requests from access tokens issued by whitelisted developer keys to receive additional claims in the JWTs of inst-fs links in the response. these additional claims are a workaround to cause inst-fs to accept the link as if authenticated despite the client not having an inst-fs session or presenting inst-fs with the access token. updated API clients will need to present their API token when accessing inst-fs links. once the clients associated with a developer key are updated, the developer key will be removed from the whitelist. this is only a temporary workaround. test-plan: - have inst-fs configured and enabled with your canvas instance - generate a new access token for your user - in the rails console of your canvas instance, set: Setting.set('instfs.whitelist_all_developer_keys', 'true') - using something without a session, like postman, POST to /api/v1/courses/:course_id/files with a valid preflight and authenticated via the access token (e.g. using the `Authorization` header) - the `upload_url` in the response should be an inst-fs link - the `upload_url` should include a `token` query parameter with a JWT as the value - decoding the JWT from the `upload_url`, it should include `legacy_api_developer_key_id` and a `legacy_api_root_account_id` claims - in the rails console of your canvas instance: Setting.remove('instfs.whitelist_all_developer_keys') - repeat the upload preflight attempt from above - this time, the JWT should not include the `legacy_api_*` claims Change-Id: I911d18c031d9ba90de808e260e4644beaef69ff9 Reviewed-on: https://gerrit.instructure.com/151690 Tested-by: Jenkins Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com> QA-Review: Collin Parrish <cparrish@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com> |
||
---|---|---|
.. | ||
coffeescripts | ||
controllers | ||
graphql | ||
helpers | ||
jsx | ||
messages | ||
middleware | ||
models | ||
observers | ||
presenters | ||
serializers | ||
stylesheets | ||
views |