Minimal Storage Abstraction

[trieloff]

We have a couple of actions now that need access to S3 or equivalent storage locations. Instead of creating a full-blown storage abstraction, what about starting with a minimal set of:

• context.storage.presignURL(bucketname: string, path: string, method?: string = 'GET', expires?: number = 60): generates a pre-signed URL for the specified bucket and path. This URL can then be used in a helix-fetch request to upload or download from storage.

For Adobe I/O Runtime we may be able to use https://github.com/adobe/aio-lib-files which has support for pre-signed URLs, but that requires the presence of @adobe/aio-lib-files in the container image.

For all others, there are libraries that can even take the credentials from the container, so we should be covered.

[tripodsan]

I don't think this will solve any problems. the idea is that we read from the same storage as the function runs. and those functions can be given the correct policies to read the storage (usually, the session key is in the env).

also, the access to the storages via fetch probably needs more than just an url. e.g. it might require an authorization header.

For Adobe I/O Runtime we...
For Azure we...

not supported :-)

[trieloff]

With a pre-signed URL, you really just need the pre-signed URL.

The problem I see is not the authentication, but that the action code itself is no longer universal but needs to conditionally load the AWS or Google client libraries, which blows up the bundle size.

[tripodsan]

action code itself is no longer universal but needs to conditionally load the AWS or Google client libraries, which blows up the bundle size.

I fear that in the future, we will have a bundle for each cloud. otherwise we cannot support ESM modules.

[tripodsan]

With a pre-signed URL, you really just need the pre-signed URL.

ah, I see:

• https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/s3-example-presigned-urls.html
• https://cloud.google.com/storage/docs/access-control/signed-urls

[trieloff]

And the pre-signing works without an extra HTTP request, so there is no performance impact.

[trieloff]

I'm wondering if we should just implement the signing ourselves (again: https://github.com/adobe/helix-pages/blob/prototype-three-fetchpool/assembly/request-signer.ts) so that we can sidestep the dependency issue entirely.

[github-actions]

🎉 This issue has been resolved in version 1.6.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀