Arvados

I haven't proven it, but I'm pretty sure this is what happened:

• The first sharing link was created.
• The collection was publicly shared so people without Arvados accounts could see the full Workbench interface.
• The token from the first sharing link was revoked. (This is the part I haven't confirmed, since activity around API tokens is scarcely logged.)

Now I'm looking at CollectionsController#show_file in Workbench. It calls Collection.find with different API tokens to look for one that it can pass along to arv-get. However, we implemented public views by passing along the defined public token as a reader token with every API request. Because of this, when the collection is shared publicly, Collection.find will always return a result. This will trick show_file into thinking that any defined token is usable, even if that's not actually case. It will use that token when it calls arv-get, and that will fail.

The easy way to get the downloads working again would be to reverse the order that show_file searches tokens for usability. This would check the public reader token for usability first: if that fails, we would be assured that it was not skewing the results in future checks. I'm going to make that change now.

This maybe raises an interesting question of whether Workbench should always fail when you make a request involving a sharing token that's been revoked. On the one hand, it might upset users to see a request still work after they revoked the link. On the other hand, it's not actually hurting anything from a strict security analysis: the collection is public, so the visitor can still get the data, they'd just have to try the token-less URL. I'm going to leave this question for another ticket.

Applied in changeset arvados|commit:b7c7f20d17afc11d2cce7bfee2205a26dc4a4762.