fixes RECNVS-481
test-plan:
- create a simple test html file
- in a canvas instance with inst-fs enabled and a files domain
- as a teacher in the course, upload the html file to a course's files
area; note the new attachment's ID
- masquerade as a different user that has permission to view the file
(e.g. a student)
- open the network tab and go to
/courses/:course_id/files/:attachment_id
- the iframe source should be a canvas url that redirects to a files
domain url that then redirects to an inst-fs URL.
- the files domain url should have an `sf_verifier` query parameter.
it should be a JWT and decoding the JWT should reveal
`real_user_id`, `user_id`, and `oauth_host` claims
- the inst-fs url's JWT when decoded should reveal corresponding
`user_id`, `acting_as_user_id`, and `host` claims
- NOTE: the html file will download instead of displaying on the iframe
on the page. this is a bug but is unrelated to this commit.
Change-Id: Iad97e9ca1007a7ceaf3e2e111df08c0339d58d78
Reviewed-on: https://gerrit.instructure.com/152950
Tested-by: Jenkins
QA-Review: Collin Parrish <cparrish@instructure.com>
Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
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>
fixes RECNVS-462
in a production-like environment, the redirect to inst-fs happens after
a redirect to the files domain. on the files domain, the user's session
is not preserved and @current_user and logged_in_user are not set. but
in their place a value indicating the user is placed in the session.
when that value is present and the current user is absent, inst-fs
should use the session value in generating JWTs.
note: currently the session value only indicates the @current_user and
any information about the logged_in_user, if different, is lost when
arriving at the files domain. this will be fixed in a separate commit;
until it is, inst-fs will not work with a files domain while
masquerading.
test-plan:
- have a canvas environment with a files domain and inst-fs enabled
- upload an image to a course
- open the network tab in the developer tools then preview the image
- there should be a `preview` request to the current domain, which
redirects to the files domain
- there should be the request to the files domain, which redirects to
inst-fs
- there should be the request to inst-fs that returns with a 200 and the
image (i.e. the preview works)
- the JWT in the inst-fs request should include the correct user_id
claim when decoded
Change-Id: Ic804b52e24739a06355df5584d3f189ae8340366
Reviewed-on: https://gerrit.instructure.com/151070
Tested-by: Jenkins
Reviewed-by: Michael Jasper <mjasper@instructure.com>
QA-Review: Collin Parrish <cparrish@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
fixes RECNVS-361
instead of just using Attachment.current_root_account.domain
to facilitate the change, all generation of non-public links to external
file storage go through a FileAuthenticator instance that holds the
necessary information about the current user and oauth host
test-plan:
[locally]
- smoke test file uploads and downloads, there should be no impact on
behavior, just a refactor
[once on beta]
- enable inst-fs in your sandbox
- logout of canvas
- open network logging in your browser dev tools and log back in to
canvas
- identify the requests related to the inst-fs login pixel and
corresponding oauth redirects
- the oauth should have occurred against your beta sandbox, not your
production sandbox
- attempt to upload a file; should be successful
Change-Id: Ic859b707908baef84f5ee4dba29f18bdd841abcc
Reviewed-on: https://gerrit.instructure.com/143930
Tested-by: Jenkins
Reviewed-by: Michael Jasper <mjasper@instructure.com>
QA-Review: Collin Parrish <cparrish@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
Jacob Fugal