refs SAS-1610
test plan:
* original_url should be in the thumbnail jwt, and include the no_cache
param
* using the original_url with the no_cache param should generate a new
thumbnail url jwt
flag = none
Change-Id: Ie1f5a01649bc6645f9766256d973d04d7ffeba9f
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/255421
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com>
QA-Review: Nathan Mills <nathanm@instructure.com>
Product-Review: Nathan Mills <nathanm@instructure.com>
closes SAS-1474, SAS-1452
canvas server-side, when:
* a canvas request would generate a redirect to an inst-fs file
* but the request also includes a `X-Canvas-File-Location` header
* and the request is session authenticated
then the server instead responds with a JSON object with:
* a `location` field containing the nominal redirect target
* a `token` field containing a token that can be used as a value for
an `Authorization: Bearer <token>` header when requesting the file
a service worker is then added that intercepts non-navigation GET
requests to those endpoints. it adds the X-Canvas-File-Location header
to the request, and then issues a followup request for the returned
location with the Authorization header added. in effect, it's following
the redirect but with the Authorization header injected. inst-fs can
then recognize the Authorization header as a means of user
authentication in the absence of cookies.
finally, the service worker is installed only if:
* the plugin setting controlling it is enabled
* the browser is Safari 13+
other browsers are able to use simpler work arounds when cookie blocking
is enabled and can thus take advantage otherwise.
test-plan:
* have canvas and inst-fs both served over https
* for safari, be using 13.1 or newer with tracking prevention enabled
* leave the service worker disabled through the inst-fs plugin setting
* have an image uploaded to inst-fs
* visit the image's preview page in the files UI:
- in safari: observe the image fails to load
- in chrome: observe the image successfully loads
* enable the service worker via the plugin setting
* refresh the image's preview page:
- in safari: observe the image now successfully loads
- in chrome: the image still successfully loads, but does so without
involving the service worker
Change-Id: Ie28f2cad40f67549bfbb4c7c6604f215581fbe18
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/237135
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
fixes SAS-1443
requires opt-in (ramping up rate in plugin setting, defaults to 0). will
initially opt in on sandbox accounts, then trial accounts, then a
gradual roll out to avoid hammering the service.
when opted in (100%), asking for a redirect target for a file that's not
yet in inst-fs will first try to add it to Inst-FS by posting the
metadata only (a nominally quick transaction). Inst-FS can use this to
create a "foreign" reference to the existing object in canvas' s3 bucket
(which inst-fs should be given access to), at which point it can
immediately start serving the object.
opting in at a level above 0% but below 100% will have the chosen chance
of doing the above per-access.
if successful, Inst-FS returns the new instfs_uuid with which the
attachment is updated, then the redirect continues to inst-fs instead of
s3. if unsuccessful, opted-out, or skipped due to opt-in threshold, the
existing s3 object is redirected to as before.
test-plan:
(setup)
- have inst-fs integrated locally
- be using an s3 backing for non-instfs files
- give inst-fs access to that s3 backing
(testing)
- turn off the inst-fs plugin setting
- upload a file
- turn on the inst-fs plugin setting, but leave the migrating flag
unset
- access the previously uploaded file, should be served from s3
- turn on the migrating flag in the plugin setting
- access the previously uploaded file, should be served (or at least
attempted, if you haven't allowed inst-fs access to the canvas s3
bucket) from inst-fs
Change-Id: I2b909d9b3f1c950e5a88f2af6ec7b40c05e71bb6
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/234167
Reviewed-by: Michael Jasper <mjasper@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
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>
Nathan Mills