Item9316: ImageGalleryPlugin breaks viewfile protection by storing files outside of Foswiki pub/web/topic structure

A change back in 2007 changed ImageGalleryPlugin to store thumbnails into pub/images/web/topic instead of the pub/web/topic structure.

This blocks use of viewfile to protect the gallery thumbnails.

See Support.Question569

-- GeorgeClark - 13 Jul 2010

Part of this stems from the inability of Foswiki to serve content other than pub/web/topic/... There's a need to cache auto-generated content, like processed images, thumbnails, pdfs, rtfs, in a place where apache can still deliver it but where it does not "pollute" the attachments area of a topic. These are typical OOB (out of band) data with the addition to make it accessible to apache.

Protecting attachments or OOB data from being served by apache then paddles backwards half way. viewfile is normally used to put Foswiki in between to enforce access control. For ImageGalleryPlugin viewfile does not fit that purpose as it is only able to deliver attachments stored at pub/web/topic/...

Solution would be to add a REST handler to ImageGalleryPlugin that fills the role of viewfile to enforce access control.

-- MichaelDaum - 20 Jul 2010

Another issue is the bypassing of any Store listeners for new "attachments". In looking at enabling Cloud storage for attachments, these files will all fall outside of of Store, and will be missed.

I don't think that a REST handler is the solution. This plugin needs an option to use the attachment API for storing all attachments including the generated thumbnails. Granted, they are relatively small files. But there really ought to be a way to include them in the Store.

-- GeorgeClark - 13 Jun 2011

Are you proposing to attach the thumbnails to the topic while they are generated? That'll generate a lot of noise I guess. The real problem at hand is that there is no working area that at the same time is also exposed to the http server. Either you pollute the attachments area (as ImagePlugin still does), or you have some other url/directory that fills that purpose. Foswiki doesn't have that feature right now. The only way to trick that into a standard install is to have a directory under /pub that is not related to a web, but still reachable for the browser. That's why there is /pub/images ... with all of the problems listed above.

-- MichaelDaum - 13 Jun 2011

I'm not sure what the optimal solution could be. Agreed that attaching as topic level attachments would be very polluting of the topic. But bypassing Store opens us up to issues as well. Maybe we need a pub/Web/Topic/_generated/Attachments (or pub/_generated/Web/Topic/Attachment ) store of some sort that can still be accessed by the Store API, but avoids some of the overhead of traditional attachments - Stored without revision history or topic metadata for example. Also storable without update permission (as "view" can generate or re-generate the files).

This task should probably be tagged as needing a feature proposal.

See SupportDynamicGeneratedAttachments

-- GeorgeClark - 13 Jun 2011

Workaround for anyone who finds this task: If you've used ApacheConfigGenerator, you can uncomment a line. If not (and you are using apache), you will want something that looks like:

# Optional - do not rewrite /pub/images if ImageGalleryPlugin is installed - path is incompatible with viewfile
RewriteRule ^/+pub/+images/+.*$ - [L,PT]

these cached images will become publicly viewable and will not be subject to AccessControl.

-- JayenAshar - 09 Jan 2012

Not the case anymore as ImageGalleryPlugin now uses ImagePlugin as a backend ... which stores thumbnails alongside of the original image.

-- MichaelDaum - 27 Jul 2017

Commenting is disabled while not logged in