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 |