Token appears in the download URL, being shared by accident
Users are sharing download URLs with embedded user tokens. Workbench2 should hand off to keep-web in a way that does not expose the token to the user.
I believe the way Workbench 1 does it is by linking to a special workbench path, which returns a redirect which includes ?api_token in the query, when keep-web gets the request it returns a cookie and another redirect to the final URL with the ?api_token stripped, this is the one the user sees, with the token safely stashed in a cookie.
The different methods of doing token hand-off are described here:
// If a token is provided in a query string or in a POST request, the
// response is an HTTP 303 redirect to an equivalent GET request, with
// the token stripped from the query string and added to a cookie
Workbench 2 collection should do something like:
- Provide "copy link to clipboard" in the context menu. The copied link must not have the token.
- This should probably be a special workbench2 link which will verify the user is logged in (or go through the login dance) and then redirect to keep-web as described next
- The "open file" and "open in new tab" behaviors should navigate to the download location with ?api_token in the query (it must not include the token in the path with "/t=.../")
- Keep-web will respond with a redirect which strips ?api_token from the URL and puts the token in a cookie.
Separate inline/download keep-web ports refs #16812
This makes inline viewing of private files work as expected with
arvbox, which is helpful for development and testing.
It relies on "TrustAllContent: true", so it is also XSS insecure.
Arvados-DCO-1.1-Signed-off-by: Peter Amstutz <firstname.lastname@example.org>
#9 Updated by Daniel Kutyła 27 days ago
New version: https://dev.arvados.org/projects/arvados/repository/arvados-workbench2/revisions/055723f58e163f0b5e49c1e8b92fd1bebe81873e
Test run: https://ci.arvados.org/job/developer-tests-workbench2/99/
Added new way of downloading files
#10 Updated by Daniel Kutyła 22 days ago
#12 Updated by Peter Amstutz 15 days ago
The "Download" and "Open in new tab" menu items need to use different links. Neither link should use the /t=.../ form for tokens.
The "Download" menu item should have "download" anchor attribute set, and open a download dialog in the browser. The download link should use the base URL from Services.WebDAVDownload.ExternalURL.
The "Open in new tab" menu item should not have the "download" anchor attribute. The link should use the base URL from
The "Copy to clipboard" should not use an open redirect. The redirect could be used to easily steal someone's token. The link should be something like:
Visiting this link should redirect the user to the file using the same link as "Open in new tab (but opening in the current tab, not a new one).
If the user arrives at Workbench2 without a token, the path should be stored in localstorage, and then restored after successful login.
#13 Updated by Daniel Kutyła 9 days ago
New version: https://dev.arvados.org/projects/arvados/repository/arvados-workbench2/revisions/9525ed95bef2a8de63b48a0682c342465d29bae9
Test run: https://ci.arvados.org/job/developer-tests-workbench2/126/
Removed download attribute, fixed redirectTo
#14 Updated by Peter Amstutz 7 days ago
So I started writing comments but I realized I didn't know what to tell you so I just went and started hacking on it. I discovered some other infrastructure issues in the process (you can see the conversation in the development gitter).
Take a look at these changes. I didn't run tests so I don't know if anything else needs to be updated.
16812-token-appears-in-the-download-URL @ arvados-workbench2|ae94f4d8463ff6350329e802cb902c8dad96a710
16812: Handoff token using query param
Need to pass the token to keep-web without it being "sticky" in the
URL bar. Using a query param accomplishes this, because keep-web
knows to strip the api_token query parameter and respond with redirect
and a cookie which the browser can use to fetch the file safely.
Also distinguish between KeepWebService (now the download service) and
KeepWebInlineService (the one that will serve content that can be
displayed inline in the browser if it is safe to do so).
#15 Updated by Peter Amstutz 6 days ago
Here's another way to try to pass the token without exposing it in the URL:
<form action="https://keep_web_url/c=.../file.txt" method="get" target="_blank"> <input type="hidden" id="api_token" name="api_token" value="xyz" /> <input type="submit" class="link-button">Open in new tab</input> </form>
#16 Updated by Daniel Kutyła 3 days ago
New version first commit: https://dev.arvados.org/projects/arvados/repository/arvados-workbench2/revisions/ffc9666a04b0cef18a15571c1a0f4fdc41e87b75
Test run: https://ci.arvados.org/job/developer-tests-workbench2/128/
Fixed tests and redirect
#17 Updated by Peter Amstutz 3 days ago
Let me try to clarify a few things.
The API that we are talking to is the WebDAV API, which is documented here:
This documentation page is new (added on Friday) so I couldn't give it to you earlier.
There are two endpoints. The "Services.WebDAV" endpoint (keepWebInlineServiceUrl) and "Services.WebDAVDownload" (keepWebServiceUrl) endpoint.
The "inline" endpoint may respond such that a browser can render the file inline.
The "download" endpoint responds so that the browser will always invokes the download behavior.
When using "open in new tab" we want the "inline" endpoint and using "download" we want the "download" endpoint.
When sending the user to the download endpoint, the ?disposition=attachement is redundant. (That parameter does change the behavior if you send the user to the "inline" endpoint).
Finally, although the way the react context menu behaves makes it difficult or impossible to right-click copy links, the link (with the token) still shows up in the browser. Instead of using an anchor tag, it should be possible to use a form to provide the token as a hidden parameter, as in my example in #note-15. Then the token won't be visible to the user.
Also, I noticed in src/services/collection-service.ts:extendFileURL it is splitting the API token and only taking the secret portion. This is wrong. It should be using the complete token, but it should be URL-encoded.
I know we have already gone back and forth on this a couple of times, I don't want you to get frustrated so if you would prefer I can also take over the branch.
#18 Updated by Daniel Kutyła 3 days ago
New version first commit: https://dev.arvados.org/projects/arvados/repository/arvados-workbench2/revisions/67d77b206ebee7c776bd4d7dbc112ebb0c7ba800
Test run: https://ci.arvados.org/job/developer-tests-workbench2/129/
#20 Updated by Daniel Kutyła 3 days ago
- Status changed from In Progress to Resolved
Applied in changeset arvados-workbench2|35ce0164f3863e7117fade1319ed3c2789bc216a.