test plan:
- create a private eportfolio with a file attachment
- get the sharing link from the eportfolio dashboard
(the thing with the long verifier in it)
- confirm that the eportfolio, and its files, are
visible through that link
(a) as a different user
(b) with no user, in a private/incognito window
- confirm that the private eportfolio is not accessible
by another/no user without the verifier
fixes CNVS-20092
Change-Id: I8dc14690068ebfc34f868d10597f95411f55c165
Reviewed-on: https://gerrit.instructure.com/53077
Tested-by: Jenkins
Reviewed-by: James Williams <jamesw@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
for verifiers that grant access to files that would otherwise
not be accessible (such as a file attachment in user context),
allow them to check permission on a different object instead.
in this commit, the verifier remaps file permissions for
eportfolio attachments to permissions on the eportfolio itself.
test plan:
- create an eportfolio, and set it to public
- attach a file to it
- verify that another user can view the eportfolio and the
file attachment
- save the URL to the file attachment
- uncheck the public eportfolio setting and save it
- verify that the saved URL for the file attachment no longer
works
fixes CNVS-19719
Change-Id: Ic1839f13d571d3f5f2aa692f94bd1fd1d5e485ca
Reviewed-on: https://gerrit.instructure.com/52120
Tested-by: Jenkins
Reviewed-by: James Williams <jamesw@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
This commit adds a new form of attachment verifier. Rather than just
being the `uuid` from the attachment object, it is a signed JWT that
includes the attachment id, the viewing user id, and a viewing context.
The existing code that checks the verifier now checks to see if it's
a UUID and returns success if it is (to preserve legacy behavior). It
attempts to decode and verify the token, and verify that the user
captured in the token still has permission to :read or :download the
attachment.
The context captured in the token is currently unused, but may prove
useful for debugging or future purposes. The context is just an
asset_string for a model.
The only place generating new verifiers with this commit is the helper
ApplicationController#verified_file_download_url, which is only used by
content exports and eportfolios.
We also shoot increments to statsd when legacy and new verifiers are
used, so we can see when legacy verifier usage is low enough to disable.
Test plan:
* Create a course export.
* View the export at /courses/X/content_exports
* Verify that the verifier= in the download URL is decoded correctly
at jwt.io. It should have a user_id, an id, and a context.
* Verify that a you can successfully download the export.
* Use the files API and verify that urls still have the
old-style verifier=<40-character UUID> on them, and that these
links still work without authentication (such as an incognito tab
or curl)
* enable eportfolios in account settings
* upload a file to user files
* create an eportfolio, and attach a user file to it
* save the eportfolio
* confirm that the download link
(which looks like /eportfolios/X/entries/Y/files/ZZZ)
redirects to a file download link with a new verifier
fixes CNVS-18858
fixes CNVS-18861
Change-Id: I3db21469462dfdb8f8067f509a01a55d7cb23abd
Reviewed-on: https://gerrit.instructure.com/48637
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Jenkins
Reviewed-by: James Williams <jamesw@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
Landon Wilkins