Q: transform route

[basz]

Hi, looking to implement image manipulation with minimal effort I found this library and have a few questions about it's general usage.

What I am trying to accomplish:

• I have middleware that returns an image on a specific route with an dynamic image id

'path' => '/dossier/dossiers/{dossier_id}/attachments/{attachment_id}',

• I want to be able to transform the image on the fly without changing the url.

So I figured my clients should request something like '/dossier/dossiers/d494a8e0-b013-447e-86e8-6a8917326bde/attachments/a9daf99d-8ec2-4450-8722-37e411a2a51c?transform=tranform-instructions' or perhaps something with the token, but I can't figure out how this should work.

I noticed the getUrl util always returns a /_/... path. Does this mean I should add an additional /_/{token} route to the application that exposes the transformed image? That would nullify the original route... So probably I'm just confused...

Looking through some code I noticed it searches for /_/ in the current requested route. So I now think I should modify the route to respond from /original/route/to/image and to /original/route/to/image[/_/*]-ish.

That would make sense. But then; In an SPA I can't easily use the getUrl utility to generate a jwt token to append to that URL. A signing a JWT on the client side wouldn't make much sense either.

What's your advice on generating and appending a transform token into a JS client.

I can think of a special service URL that is user protected to generate those tokens but it would mean an additional round trip...

Thanks for the excellent work here...

[oscarotero]

This middleware does the following:

• The getUri static function encode the image path and the transform instructions into a JWT payload using the token provided.
• Then, it converts the JWT payload into a valid path, using / to divide the payload into subdirectories and avoid names larger than 200 characters (they are problematic in some servers).
• So the token is not used only to append the transform instructions to the image, but to encript the whole url path.
• This middleware, in the first step does the opposite: get the JWT payload from the uri, parse it and restore the uri with the original file path. Then send the request to the inner middleware.
• Then, get the response (that should contain the image data in the body) and performs the transform instructions to the image.

The /_/ is used to distinguish between uris containing JWT tokens and real uris. It's useful also to save the transformed image into a /_/ folder (a kind of file-based cache), so the next time the same image is requested, it could be served as a static asset.

A real example of this middleware in use is this website: https://historia-arte.com/ For example, this image url https://historia-arte.com/_/eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpbSI6WyJcL2FydGlzdFwvaW1hZ2VGaWxlXC9ob3BwZXItc2VsZi1wb3J0cmFpdC5qcGciLCJyZXNpemVDcm9wLDUwLDUwIl19.Qp7aqy1beHV7bULQoZHaoxXmahGmzRmEtCyHlBWa5Us.jpg is generated in the first request and then served statically the next times using a simple nginx/apache directive.

Not sure if this helps you