Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Signed URL with Cloudfront #104

Open
tomasz-tomczyk opened this issue Aug 28, 2022 · 4 comments
Open

Signed URL with Cloudfront #104

tomasz-tomczyk opened this issue Aug 28, 2022 · 4 comments

Comments

@tomasz-tomczyk
Copy link

Environment

  • Elixir version (elixir -v): 1.14.0-rc.0
  • Waffle version (mix deps): 1.1
  • Waffle dependencies when applicable (mix deps): N/A
  • Operating system: OSX / Alpine

Expected behavior

I was hoping to use Cloudfront with signed URLs and after configuring it in AWS, I confirmed it just works with both the Cloudfront URL and alternate domain I configured in Cloudfront by just changing the host of the URL generated by waffle/ex_aws:

App.Uploads.ProfilePhoto.url(:thumb, signed: true)
|> String.replace(
  "https://s3.eu-west-2.amazonaws.com/my-bucket-name/",
  "https://dhb50ml2ixxxx.cloudfront.net/"
)

I expected this to just happen if I was to configure the asset_host

Is there a better way to do this than add my own wrapper that changes the url?

Actual behavior

Generating a signed URL always returns a S3 URL

@darwin67
Copy link

Same here. Would be nice that the asset_host is respected when using signed URLs.

@JacobAlexander
Copy link

bump, it is almost 2years and the issue still exist

@achempion
Copy link
Member

My main concern is that some of the deployments can rely on existing logic, and it could break signed URLs for those who don't use Cloudfront for the asset host. I'm thinking about introducing signed_asset_host option that would work similarly to asset_host but used only for signed URLs. Please let me know your thoughts on this

@tomasz-tomczyk
Copy link
Author

Perhaps it could be a separate option for now but whenever you're considering a major release bump, it could become the norm? Appreciate it's not big enough thing to warrant a major release now.

Major version releases normally come with potential breaking changes so IMHO it's OK when you do eventually come around to it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants