Just stumbled upon riapi via imageflow.io and it looks like a really promising spec and really dig to idea to standardize this somewhat.
Not sure if this has been discussed yet (hope I didn't miss any ticket or a paragraph in the spec) - or if this is even considered to be in scope for riapi, but allowing the client to fully control sizing, composing etc. also leaves a door open for bad client behaviour. A bad client I could think of is one that starts to request the following images and filling up the local cache / S3 storage / processing CPU usage:
/image.jpg?width=1&height=1
/image.jpg?width=2&height=2
/image.jpg?width=3&height=3
...
While not all are probably affected by this - people running a dynamic image resize service (even with a cache in front) on Heroku might be hit by this rather quickly 😄
Personally I think it would maybe make sense to either (A) clearly state the this kind of behaviour needs to be blocked or handled server-side (e.g. rate limiting, filtering allowed options, hiding via a proxy etc.) or (B) provide an option to create paths that can't be tampered with by the client, when they are generated by a trusted party.
One solution for option (B) could be adding signature= parameter that is generated on the server side using a shared secret, this is something that probably could work well for most of webapps, blogs and similar use-cases. The basic idea is to generate a signature with the path, params and the shared secret (e.g. using HMAC SHA256) and then appending this to the url, this would allow to be easily checked on the server side and still allows trusted peers to create any image they want, without re-configuring the image server. However this would work not so well I guess for (some) native apps, where each device might request a different image size, depending on the screen size and embedding the shared secret basically voids the safety added. Yet even apps might want to be limited to some fixed sizes...
What are your thoughts and opinions about this topic - or is it out-of-scope for the idea of riapi?
Just stumbled upon riapi via imageflow.io and it looks like a really promising spec and really dig to idea to standardize this somewhat.
Not sure if this has been discussed yet (hope I didn't miss any ticket or a paragraph in the spec) - or if this is even considered to be in scope for riapi, but allowing the client to fully control sizing, composing etc. also leaves a door open for bad client behaviour. A bad client I could think of is one that starts to request the following images and filling up the local cache / S3 storage / processing CPU usage:
While not all are probably affected by this - people running a dynamic image resize service (even with a cache in front) on Heroku might be hit by this rather quickly 😄
Personally I think it would maybe make sense to either (A) clearly state the this kind of behaviour needs to be blocked or handled server-side (e.g. rate limiting, filtering allowed options, hiding via a proxy etc.) or (B) provide an option to create paths that can't be tampered with by the client, when they are generated by a trusted party.
One solution for option (B) could be adding
signature=parameter that is generated on the server side using a shared secret, this is something that probably could work well for most of webapps, blogs and similar use-cases. The basic idea is to generate a signature with the path, params and the shared secret (e.g. using HMAC SHA256) and then appending this to the url, this would allow to be easily checked on the server side and still allows trusted peers to create any image they want, without re-configuring the image server. However this would work not so well I guess for (some) native apps, where each device might request a different image size, depending on the screen size and embedding the shared secret basically voids the safety added. Yet even apps might want to be limited to some fixed sizes...What are your thoughts and opinions about this topic - or is it out-of-scope for the idea of riapi?