Item9316: ImageGalleryPlugin breaks viewfile protection by storing files outside of Foswiki
Current State: Closed
Released In: n/a
Target Release: n/a
A change back in 2007 changed ImageGalleryPlugin
to store thumbnails into
instead of the
This blocks use of viewfile to protect the gallery thumbnails.
- 13 Jul 2010
Part of this stems from the inability of Foswiki to serve content other than
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.
is normally used to
put Foswiki in between to enforce access control.
does not fit that purpose as it is only able to deliver attachments stored at
Solution would be to add a REST handler to ImageGalleryPlugin
that fills the role of
to enforce access control.
- 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.
- 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.
- 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
) 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.
- 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
- 09 Jan 2012
Not the case anymore as ImageGalleryPlugin
now uses ImagePlugin
as a backend ... which stores thumbnails alongside of the original image.
- 27 Jul 2017