Is it possible to disable the Large Image/OpenSeadragon clipping tool?

98 views
Skip to first unread message

Brandon Weigel

unread,
Nov 20, 2017, 10:38:29 AM11/20/17
to islandora
One of our sites wants to make it harder for users to download Large Images, hoping that they will contact the owners for permission. They wish to disable the clipping tool that appears by default in the viewer.

Is it possible to disable this clipping tool? I don't see any options to do so in the viewer settings nor the Large Image SP settings.

dp...@metro.org

unread,
Nov 21, 2017, 11:51:18 AM11/21/17
to islandora
Hola Brandon,

I see a few options for disabling the clipping. (but be aware that does not block the access to the image at all, anyone can put into the URL  islandora/object/YOUR:PID/datastream/JP2/view and bypass the whole logic if the JP2 image is open to the world, same goes with OBJ, etc and openseadragon actually requires adore-djatoka to be exposed on port 80, finally,  webbrowser inspectors/consoles will allow smart folks to even bypass most of your options.
You could maybe add a watermark to the JP2 datastream dynamically on derivative creation using some creative image magick coding and then just block via XACML the OBJ datastream?


back to the original question, for clipping:
The current access call back is just the islandora_object_view. I can imagine a scenario where a separate permission could be enable to actually block that completely for anonymous users. Requires altering the menu and adding your own access callback from your own contributed module.

2.- Add an extra preprocess hook (in your own module) that actually gets rid of the clipping processing generate at https://github.com/Islandora/islandora_openseadragon/blob/60018c64ccc84e8ec0174014b263c38348bb0798/islandora_openseadragon.module#L140

3.- Add the watermark on the fly on the clipping result?

4.- Add a switch (we have so many!) into islandora_openseadragon to actually disable clipping at all

replacing it with your own, that throws always a drupal_denied,

And any combination of those,

Hope this helps

Best!

Diego

Mark Jordan

unread,
Nov 21, 2017, 11:55:19 AM11/21/17
to isla...@googlegroups.com
Hi Brandon,

In addition to using XACML, another option for blocking access to specific datastreams is https://github.com/mjordan/islandora_restricted_datastreams.

Mark
--
For more information about using this group, please read our Listserv Guidelines: http://islandora.ca/content/welcome-islandora-listserv
---
You received this message because you are subscribed to the Google Groups "islandora" group.
To unsubscribe from this group and stop receiving emails from it, send an email to islandora+...@googlegroups.com.
Visit this group at https://groups.google.com/group/islandora.
To view this discussion on the web visit https://groups.google.com/d/msgid/islandora/f4178142-5809-48ea-9192-f0d7786cc93a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Brandon Weigel

unread,
Nov 21, 2017, 3:07:35 PM11/21/17
to islandora
Thanks, Diego. I like the suggestion to dynamically add a watermark to the clipping result... I don't suppose there's a simple way to do that?

I'm playing with the idea of making the clipping tool a configurable thing in the Large Image CModel right now.

Peter MacDonald

unread,
Nov 21, 2017, 3:35:28 PM11/21/17
to islandora
In April of last year we were all encouraged to disable the download clip tool for security reasons, as follows

"On Friday, April 22, 2016 at 1:26:36 PM UTC-4, Islandora wrote:
A security issue has been identified in core Islandora by Mitchell MacKenzie that would allow an attacker to use some of its endpoints as open proxies. A hotfix patch has been developed for immediate application that disables the functionality of these endpoints. It takes the form of two modules, each of which closes one of the endpoints in question. Updates for the modules affected have also been proposed and will be released as soon as possible so that the patched functionality can be restored.
Drupal's security risk level definition would qualify this vulnerability as:
11/25 (Moderately Critical) AC:Complex/A:None/CI:Some/II:None/E:Theoretical/TD:Default
The risk is mitigated by the fact that it requires an above-average knowledge of the internals of Drupal and the Islandora stack to discover and exploit, and by the fact that server configuration can plug potential targets of open proxies.

I still have that module enabled on my Islandora instances.

Was that supposed to be just a one-time fix? Do I need to keep that module enabled or is it no longer necessary?

BTW. We're now running Islandora 7.x-1.9.

I'm confused, as usual.

Peter

Bill Levay

unread,
Nov 25, 2017, 8:44:11 PM11/25/17
to islandora
Hey, just chiming in that we'd love to be able to disable the Clip Image tool on certain collections of Large Images, but not all. I was thinking one way to at least hide the Clip Image link would be to use the Context module to trigger a CSS rule that would add a "display: none" to the Clip Image element, just for certain collections. (I guess this is a version of Diego's #6 option above, but with some conditional logic.) I haven't tested this out yet, and of course the savvy user would still be able to download the datastream, but we might have to give it a try for the time being.

Bill

dp...@metro.org

unread,
Nov 26, 2017, 7:39:05 PM11/26/17
to islandora
Hi Brandon,

There are many ways of doing watermarking and which one works for you will actually depend on how much code and how you want to solve the issue with real-time performance/caching/where-you-want-to-water-mark (many layers).  This is the most simple tut I could find for you http://www.rainbodesign.com/pub/watermark/ (forget the CSS one, too simple+bad)

This (our own) forum is actually an invaluable source of information (so many years). Look at this one 
https://groups.google.com/forum/#!topic/islandora/AIwtPlHqlmo : happens that Adore has a watermark plugin!. But since adore is older than our forums, documentation is lost, You will have to experiment with the settings (see this https://sourceforge.net/p/djatoka/mailman/djatoka-devel/?viewmonth=200910)

And http://www.imagemagick.org/Usage/annotating/#watermarking (basically the ImageMagick way, so you could do something like that directly via PHP or as a derivative)
his islandora user proposed his way of doing watermarks with code: https://groups.google.com/d/msg/islandora/PEmHAk33hvg/PR2dRoumZJIJ
(2012!!)

Well: the way i would do it:
1.- In my own module: create a new/replacement callback datastream view access that targets specificly JP2 and/or OBJ. The idea here is to override islandora's default datastream provider with some extra logic but without the need to change every other module (or even djatoka) that are tied to being able to read JP2/OBJ datastreams. The override should do the following:
a) if the user is logged in, just bypass your logic and call the original menu router callback.  So user asks OBJ, gets OBJ
b) if the user is anonymous, check if your object has a datastream called "WM" or any other name you want to use to store your watermarked image(which you don't have yet). You could also check for the existence of a CDN file that matches (or a file stored in drupal's tmp or public folder ) e.g.{$PID}_watermark.jp2. In case the DS or the file actually exist you serve that one, if not, well you can then generate dynamically via GD/imagemagic a watermark and populate that "WM" DS or the temporary file. If you want to go "pro" you can of course query all large image objects and pre-generate those and even add in your own module a derivative that creates the watermarked image based on that JP2.So user or djatoka asks for OBJ or JP2, gets WM

Whatever you do, the key is creating your own menu router that deals with OBJ and JP2 for anonymous, making the access to either the full image or the watermarked completely transparent to other modules

Hope this helps, just some ideas

D




On Tuesday, November 21, 2017 at 3:07:35 PM UTC-5, Brandon Weigel wrote:
Reply all
Reply to author
Forward
0 new messages