"Private" links to S3 files

1

We use a workflow (Integromat) which automatically stores email attachments and various metadata in an S3 bucket (and folders), and a Lambda function which upserts a row in a Coda table with link, key, meta, etc.

The problem we have is around file permissions on S3. We don’t want to have the bucket Public, yet want our doc editors to be able to open the file links via a browser.

  1. We tried to use buttons containing the file links which trigger an OpenWindow(thisRow.[route] action ([route] column is the S3 URL), as I read somewhere that read-only users can’t press buttons - that appears not to be true.

  2. I suspect we could make an IAM user specifically for this purpose, and pass those creds via an HTTP call to an S3 Get request, and then do an OpenWindow action. Problems are, (a) there’s no URL present in the Get response - so don’t know how to get there, and (b) if there were, the column, hidden or not, would be visible to all anyway.

  3. Our entire data store is in one Doc, with pages/subpages. We’re still a bit unclear about sharing/permissions - perhaps one answer is to refactor the schema into different docs or sections… although we still don’t have clarity about permissions vs workspace/sections/docs - would we, for instance put sensitive tables / info into another doc/section/workspace and use cross-doc? Any help on sorting out organization schemas would be helpful.

Goal is to make the bucket private, somehow pass creds to S3 so that only Coda can open the file in another browser tab - or something to that effect. Happy to build a pack that does this, though we’re obviously not clear how to effect this.

One possibility could be downloading the file to Coda temporary cache, and (or local storage) and opening a tab from there…

Any thoughts out there?

1 Like
2

In packs, a simple solution might be to use TemporaryBlobStorage - Coda Pack SDK to temporarily copy a file onto a Coda domain. These copies will be slow and expensive, so you’d probably want to have a button that does it on-demand when someone’s trying to open a link.

Another option that’d be significantly harder to implement but that’d have some nice properties in theory (like being faster and more flexible) would be to generate “presigned” s3 URLs which allow you to share a secret link to a private s3 file with an expiration date of up to 7 days. These URLs can be generated entirely client side if you have the right private credentials available, so there wouldn’t be any delays or extra computation when someone clicks a link: it’d just immediately open

2 Likes
3

Thanks, David - looking into these.

1 Like
4

David, Thanks again. Upon further inspection, I agree that the first solution is less straightforward (and potentially clunky) than the second. Presigned URLs appear pretty trivial and painless using a Lambda endpoint and AWS’ Javascript SDK V3. I’ll report my findings!

1 Like
5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.