Text fields: embedded image URLs should be absolute? about reservoir HOT 5 OPEN

Most people want their backends to have the smallest exposure possible. In this case (Reservoir) that would be done by only allowing requests to /jsonapi/* URLs from public IP ranges.

from reservoir.

Wonderful! Glad to hear you were able to very quickly get started 👍

Reservoir (Drupal) is intentionally providing root-relative file URLs: so that you can easily prefix it with whichever host you're letting serve static files. Many will want to use a CDN. Others will want to set up Varnish or nginx. And more importantly: to prevent problems when switching from your dev environment to your prod environment.

If we'd be returning absolute URLs, and you would be using those directly, then it'd be trivial to figure out the back end's URL. You probably don't want to expose Reservoir to the world.

If you do want to use Reservoir's web server directly (which makes total sense for development), then the same base URL that you use to talk to Reservoir can also be used to access static files. In production, you'd change this to a CDN base URL.

Thoughts?

from reservoir.

Hello !
Good points, but how i am supposed to "prefix" url ( from my front-end ) when it is inside html of a rendered body ?

from reservoir.

Oh, I thought you were referring to a file URL for the "Image" field! But you're referring to a file URL embedded in the rich text. That's … a very good point.

I can think of multiple approaches:

• in your client, you can parse this HTML, then do querySelectorAll('img[data-entity-type=file]') to get all relevant img tags, and prefix their src
• Reservoir could remove the ability to have embedded images
• Reservoir could add a filter with a "static file URL" setting that's exposed in Reservoir's UI, and then combined with https://www.drupal.org/node/2626924, there would not just be field_body[value], but also field_body[processed], which would then contain the absolute file URL

Thoughts?

from reservoir.

I would say that it does not makes much sense from a client-side perspective to receive a rendered body with "broken" links. This add extra works on each client ( we may have several clients pointing to the same reservoir ) to fix those urls. This is not hard but it has to be replicated and maintained on all clients.

So I would expect an option in reservoir to send processed urls. This allows to configure CDN from reservoir (or to simply use reservoir server url), and reservoir is able to propagate right urls to all clients.

I dont see the issue with "then it'd be trivial to figure out the back end's URL", my XHR requests reveals it anyway

from reservoir.