Derivation endpoint public uploads

[gczh]

I am currently using the new derivations endpoint with cloudflare r2. These are my settings:

prefix = if ENV["FORCE_R2"] == "true"
  "uploads/dev"
else
  "uploads/store"
end

Shrine.plugin(
  :derivation_endpoint,
  secret_key: Rails.application.credentials.secret_key_base,
  prefix: "derivations/image",
  public: true,
  upload: true,
  upload_options: { acl: "public-read" },
  upload_redirect: true,
  upload_redirect_url_options: { public: true },
  host: "https://assets.aitoolsfor.co/#{prefix}",
)

When doing image.derivation_url(:thumbnail), this is what I get

https://assets.aitoolsfor.co/uploads/store/derivations/image/thumbnail/eyJpZCI6Ijk3NDUzMDMxOWNhY2FkYzcwYTk2YjlkZGY3YTE4MThmIiwic3RvcmFnZSI6InN0b3JlIn0?signature=ee8027a7002675edcfb345955a9211b39e80dfd415873db46597f50820fd8c3d

This is incorrect as on R2's interface, it's stored at aitoolsfor-production/aitoolsfor-production/uploads/dev/974530319cacadc70a96b9ddf7a1818f/

The file is named thumbnail-400-80.jpeg

How do i get the derivations_endpoint to redirect users to that instead?

The reason why I'm not generating a signed URL is because I want these images to be publicly accessible (so they can be indexed by Google and appear in images search)

[janko]

The derivation URL doesn't have anything do with the direct file URL on the storage. It's just the URL to your app that will trigger processing and uploading, and in your case redirect to the processed file on the storage. Doesn't your derivation URL redirect to the expected location?

[janko]

Isn't https://assets.aitoolsfor.co the domain of your app? How can the derivation endpoint be redirecting to your app? Is this really the value of the Location header of the derivation URL response? If this is really the URL it's redirecting to, then what is the generated derivation URL? Note that we're talking about two URLs, the derivation URL and the redirected file URL, you only provided one.

[gczh]

Oooh @janko you're right haha. I think i know why I'm confused now!

For cloudflare R2, it's a little tricky:

1. There's the API endpoint
2. There's the public bucket endpoint (https://assets.aitoolsfor.co is that endpoint)

Cloudflare doesn't allow the API endpoint to be used to serve the assets publicly. But shrine is currently redirecting to that endpoint instead of the public bucket endpoint.

Is there any way I can configure Shrine to set the redirection to the public bucket endpoint instead of the API endpoint?

Once again, thank you so much for pointing me in the right direction! Those were good questions!

---

1. The image derivation url for the thumbnail is: http://localhost:3000/derivations/image/thumbnail/638/480/eyJpZCI6Ijk3NDUzMDMxOWNhY2FkYzcwYTk2YjlkZGY3YTE4MThmIiwic3RvcmFnZSI6InN0b3JlIn0?signature=1143bffc015e44046bef856bae4e24e3d097d211381a0f8b067229df4fee1fac

2. It redirects to https://aitoolsfor-production.xxxxxxxxx.r2.cloudflarestorage.com/aitoolsfor-production/uploads/dev/974530319cacadc70a96b9ddf7a1818f/thumbnail-638-480 (the filename and buckets are correct, but not the base URL – it should not be the R2/S3 API endpoint but the R2 public url which is assets.aitoolsfor.co)

[janko]

If you're using Shrine::Storage::S3 for R2 (I seem to recall it was S3-compatible), then you can pass the :host option to :upload_redirect_url_options plugin option. Generally, whatever options you would normally use to generate the a public URL of the original file, those same options should be passed to :upload_redirect_url_options, because the same call to Shrine::UploadedFile#url is done internally.

[gczh]

@janko I ended up using this with the above settings, and like you said, and it works! Thank you!

Shrine.plugin(:url_options, store: {
  host: "https://assets.aitoolsfor.com",
  public: true,
})

And that did the trick. However, I think the 301 permanent redirects might be slowing down image load times. As opposed to simply just loading from the R2 public url right away.

This affects how fast the page loads and thus affects SEO. Is there anyway you'd suggest getting around this?

[janko]

The browser should remember a 301 redirect, and next time retrieve the image straight from the storage. However, derivation_endpoint returns a 302 by default, so it will happen every time. In either case, there will be a HEAD request made to the storage to check if the processed file exists.

A solution would probably be to store processed file references in the database. This could put more load on the DB (N+1s), but probably result in less overhead. Shrine doesn't implement this.