Minimal Storage Abstraction about helix-universal HOT 7 CLOSED

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 :-)

from helix-universal.

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.

from helix-universal.

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.

from helix-universal.

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

from helix-universal.

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

from helix-universal.

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.

from helix-universal.

🎉 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 📦🚀

from helix-universal.