Bug #16812

Token appears in the download URL, being shared by accident

Added by Peter Amstutz about 1 month ago. Updated 2 days ago.

Assigned To:
Target version:
Start date:
Due date:
% Done:


Estimated time:
(Total: 0.00 h)
Story points:
Release relationship:


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
// instead.

Workbench 2 collection should do something like:

  1. Provide "copy link to clipboard" in the context menu. The copied link must not have the token.
    1. 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
  2. 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=.../")
  3. Keep-web will respond with a redirect which strips ?api_token from the URL and puts the token in a cookie.


Task #16882: Review 16812-token-appears-in-the-download-URLResolvedPeter Amstutz

Associated revisions

Revision 8127b5d5 (diff)
Added by Peter Amstutz 7 days ago

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 <>

Revision 35ce0164
Added by Daniel Kutyła 3 days ago

Merge branch '16812-token-appears-in-the-download-URL'
Closes #16812

Arvados-DCO-1.1-Signed-off-by: Daniel Kutyła <>


#1 Updated by Peter Amstutz about 1 month ago

  • Subject changed from Token appears in the URL, being shared by accident to Token appears in the download URL, being shared by accident

#2 Updated by Peter Amstutz about 1 month ago

  • Description updated (diff)

#3 Updated by Peter Amstutz about 1 month ago

  • Description updated (diff)

#4 Updated by Peter Amstutz about 1 month ago

  • Target version set to 2020-09-23 Sprint

#5 Updated by Peter Amstutz about 1 month ago

  • Assigned To set to Daniel Kutyła
  • Category set to Workbench2

#6 Updated by Peter Amstutz about 1 month ago

  • Description updated (diff)

#7 Updated by Peter Amstutz 29 days ago

  • Target version changed from 2020-09-23 Sprint to 2020-10-07 Sprint

#8 Updated by Peter Amstutz 29 days ago

  • Status changed from New to In Progress

#11 Updated by Peter Amstutz 16 days ago

  • Target version changed from 2020-10-07 Sprint to 2020-10-21 Sprint

#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 Services.WebDAV.ExternalURL.

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.

#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>

#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.

#19 Updated by Peter Amstutz 3 days ago

I think you committed "open-in-new-tab.actions.ts" by accident.

Otherwise LGTM.

#20 Updated by Daniel Kutyła 3 days ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF