Update UV to support degraded images

[snydman]

Update UV version in SUL-Embed to support degraded initial view implementation, like:

http://universalviewer.io/examples/#?c=0&m=0&s=0&cv=0&manifest=https%3A%2F%2Fiiifauth.digtest.co.uk%2Fmanifest%2F11_kitty_joyner&xywh=-1587%2C-121%2C5573%2C3239

[mejackreed]

Do we have some examples of our own content that has the degraded image support?

[mejackreed]

This may need some enhancements from stacks. See https://iiifauth.digtest.co.uk/img/11_kitty_joyner_degraded.jpg/info.json vs https://stacks.stanford.edu/image/iiif/bb537hc4022%2Fbb537hc4022_001/info.json

[mejackreed]

Ok I found one: bs305hw1485

See: https://sul-purl-uat.stanford.edu/bs305hw1485

Everything seems to "work" though the blank dialog to "confirm" is kind of strange

[tomcrane]

Copying this info from an email:

I've added another example to the Auth demo site that shows how some of the size and/or zoom restrictions can be implemented, with a combination of maxWidth and the auth sequence for degraded resources.

The scenario: Anyone can zoom, but only authed users can download a hi res image.

In this example, the unauthed client requests the advertised image service. It is redirected to another service, that is identical apart from the presence of maxWidth in the profile:

https://iiifauth.digtest.co.uk/img/11_kitty_joyner.jpg/info.json

redirects to

https://iiifauth.digtest.co.uk/img/11_kitty_joyner_degraded.jpg/info.json

The maxWidth of 512 is sufficient to allow tiling and therefore deep zoom (in fact it could have been 256 for this service).

The client observes that a redirect has occurred, and also observes that the service has auth services available. It can then offer the login UI.

In the demo site's case it's a modal, but it a more sophisticated client (e.g., UV) that offers a different experience for degraded services, the login call to action is alongside and doesn't prevent the unauthed user interacting with OSD and zooming.

If you decline the login interaction, you can still zoom in, but the download link won't work (and the client knows it won't work so normally would not offer it).

If you accept the login interaction ("username", "password"), then you can zoom in as before, but you can also download the hi res image.

Demo:

https://digirati-co-uk.github.io/iiif-auth-client/?image=https://iiifauth.digtest.co.uk/img/11_kitty_joyner.jpg/info.json

The same image service wrapped in a manifest: https://iiifauth.digtest.co.uk/manifest/11_kitty_joyner

In the UV, with "alongside" UI (because it treats degraded differently):

http://universalviewer.io/examples/#?c=0&m=0&s=0&cv=0&manifest=https%3A%2F%2Fiiifauth.digtest.co.uk%2Fmanifest%2F11_kitty_joyner

The client has enough information to generate the required UX, and this pattern can be used for a variety of download/zoom restrictions.

[mejackreed]

@tomcrane Is there the option in UV to skip the second dialog window (see screenshot) and then just continue through to auth service after a user clicks the initial "login" button?

[tomcrane]

@mejackreed It doesn't work like that right now, but I think it could be made to. The issue is ensuring that the whole interaction through to opening the third party window happens on the same event loop triggered by the initial user interaction (in this case clicking the link in the yellow bar), otherwise it will be blocked by popup blockers.

http://iiif.io/api/auth/1.0/implementation/#event-initiation

The text in the yellow bar would also need to come from the service description in the info.json, the spec requires that you show that to the user before they initiate the action.

[edsilv]

Regarding opening from the login button in the yellow bar: https://github.com/sul-dlss/universalviewer/issues/33#issuecomment-317868014

The text in the yellow bar is now set from the info.json

[mejackreed]

With the upstream changes, I think I would say this issue is closed now. More detailed issues about auth/login should be opened separately