Keep-web flow » History » Version 3
Peter Amstutz, 12/18/2015 04:32 PM
1 | 1 | Peter Amstutz | h1. Keep-web flow |
---|---|---|---|
2 | |||
3 | Keep-web serves files from Keep collections as normal HTTP documents. |
||
4 | |||
5 | Considerations: |
||
6 | |||
7 | We are serving arbitrary files, which can include HTML files with Javascript. We don't want serve these files as regular documents from Workbench, because this would expose a cross-site-scripting (XSS) attack where the HTML page is loaded and executed with the credentials of the viewing user. |
||
8 | |||
9 | This is mitigated two ways: |
||
10 | |||
11 | # By serving files with "content-disposition: attachment" which tells the browser to open up the download dialog straight away and don't try to show the files. |
||
12 | # Using separate a separate domain for downloading, so the browser won't send workbench cookies. |
||
13 | |||
14 | This raises the challenge: how to provide the API token to keep-web to enable download? |
||
15 | |||
16 | 3 | Peter Amstutz | keepweb accepts an API token the following ways: |
17 | |||
18 | * With @Authorization: OAuth2@ header |
||
19 | * With @Authorization: Basic@ header |
||
20 | * With @?api_token=xxx@ query string |
||
21 | * With a cookie called @arvados_api_token@ |
||
22 | * With @/t=xxx/@ at the start of the path |
||
23 | |||
24 | Constraints: |
||
25 | # when doing a GET request, the API token must be either part of the request URI or a header (browser does not send the workbench cookie when keep-web is on a different domain) |
||
26 | # We want to hide the API token from the user unless it is a "sharing" link |