concerns about new "download" link to get attachments

[Frederic Malenfant]

Hi, I read your post about the new "/download/", and the new way to download attachments, specially for users using API.

https://trello.com/c/oIHLR6b1/85-authenticated-access-to-s3

I had to do similar implementation using other API, and I think that you're the only one who will "always" require to pass the token + key.

I think that will make it too easy to get our token lost in the public, as I can just click a url in a browser to give it to a friend, and I don't know that my secret key is in it.

If someone uses a browser, and it is already logged to trello, is it possible that, followint the download link WITHOUT key / token, opens the url?

https://api.trello.com/1/cards/xxx/attachments/yyy/download/

Automatically starts download if if the user is connected to trello UI and has the right to download it.

Or, redirect to the "login page" if the user is not connected, then start download.

I understand that, from server-side, it's impossible to do that, and it's very nice to be able to get the document using the key-token querystring.

But, in all other cases, like in a browser, or if I export some informations, including download links of files, I really don't want to include these informations.

Actually, we provide functionality to export attachments (descriptions), including download urls.  We know that these were insecure, and I totally understand why you now require an authentication.

But, again, I think that, from the download link, WITHOUT querystring, the download should start if the user is logged, or if he "can" login from your login page, and then be redirected to that file. 

That's the behavior I see in all other application API that need to provide attachments download.

[Iain Dooley]

@Frederic Malenfant I think you just get back a URL in the payload to which you can attach a key/token or you can get a link that will expire within a given timeframe. As far as I can see there's no chance you'd be accidentally copying and pasting a link from a web browser then giving it to someone else, however you would be better off posting about your concerns on the developer community site, here's the relevant post:

https://community.developer.atlassian.com/t/authenticated-access-to-s3/40647?_ga=2.131524687.1164060461.1598221099-299049771.1576052240

[Frederic Malenfant]

Yes, we can add the links just before downloading the file, but in the browser history, the keys will aways be there.  Also, if I export the urls, they will be in valid in 1 hour.  They should provide a "permanent url" that will redirect to login page.  I'll continue in the link you provided, thank you.

[Iain Dooley]

@Frederic Malenfant If you're providing a link from which people can permanently download, and that link contains the key and token, then yes the key and token will be exposed but that's not an API problem that's a problem with your implementation.

If you want to provide a permanent link that doesn't expose key and token then you will need to store a key and return a 302 redirect after authenticating the same as Trello does itself. Those URLs won't be stored in the browser history.

[Frederic Malenfant]

I disagree, when you say "the same as Trello does itself", in their UI, they are still linking to the insecure permanent s3 link.  That's the worst implementation of documents of all providers I have to code.

If I give you a link to a very secure task, it's not because you have the link that you can open it, you must be authenticated.

But, if I give you a link to any document in that task, you can open then directly.  You can say that I just don't have to give you the link.  Trello seems to think that, because the link is impossible to guess, their documents are secure.  But, you can't guess a task ID also and open that card.  

So, they try to make download document more "secure" using their api, with that temporary 1 hour s3 link.  But it looks like they will not do that in their UI. 
One people in a company can just forward a task e-mail with that document link, and anyone who can't read the card, is able to open the document.  Just hit "open in a new tab" and you get the public insecure permanent document link.

There should be a "permanent_url" that you can share, and the person who use it must be authenticated and have the right to view the document when they follow that link.

A secret document inside a secret card should be as secure as the card itself.  Asking for authorization when called from the api, but giving the "public url" in the UI, is not a solution. 

They should use the same security on both endpoint.