UV does not call access cookie service for "tiered access" image that specifies Kiosk interaction

[markmatney]

UV version:

 [email protected]
 [email protected]

I'm submitting a:

• [x] bug report
• [ ] feature request
• [ ] support request

Current behavior:

After fetching an info.json that (after a 302 redirect) includes an access cookie service, UV does not make a request to the service.

Expected behavior:

I would expect UV to make a request to the access cookie service (so that it can then make a request to the access token service, in order to fetch access-restricted resources), per the IIIF Authentication API 1.0 spec.

Steps to reproduce:

1. Either:
   • Visit https://codesandbox.io/s/uv-simple-example-forked-m1o25o; or
   • Visit one of (a) https://uv-v3.netlify.app or (b) https://uv-v4.netlify.app, set the manifest URL to https://test.iiif.library.ucla.edu/auth-test/manifest, and navigate to the second Canvas (labeled "tiered")
2. Note that the access cookie service is never called (and as a result, neither is the access token service)

Other information:

May be worth comparing with Mirador 3's implementation, which works as expected.

[nicolasfranck]

Same here, both for v2 and v3 manifests:

• v2: https://heaney0.ugent.be/IIIF/manifests/archive.ugent.be%3A3C37B88E-0BE3-11E6-9682-B54FF264C48D
• v3: https://heaney0.ugent.be/custom-manifests/v3_manifest.json

instead of seeing a dialog saying that you have to login, you are presented with a small dialog saying Cannot read properties of undefined (reading 'message').

After debugging I found out that it is stalling at HeaderPanel.prototype.showInformation after having received an event of type SHOW_INFORMATION. But that does not make any sense, as it is not given the right data type. Apparently it is coming from Auth1.showDegradedMessage, which comes from Auth1.handleMovedTemporarily. The id of the info.json is exactly the same so I have no idea why it is interpreted as a degraded access.

[nicolasfranck]

Besides, that HeaderPanel.showInformation is given an array of objects (of type InformationArgs), while it is treated as if it is given only one object. That is why this line return a null

[nicolasfranck]

Mm, the interpretation as a degraded resource has probably something to do with this line: if your image id contains an url encoded path, then the encoded path is different, and so interpreted as different. Why is this unencoded anyway?

Although this does not fully fix this.

[stephenwf]

I've fixed a few related issues to this, there is a sandbox here: https://codesandbox.io/s/uv-react-demo-forked-ecywzj?file=/src/App.tsx:2581-2680 where you can test with your own manifests. You may need to open the sandbox preview in its own tab to test (https://ecywzj.csb.app/).

[markmatney]

Thanks @stephenwf -- I should be able to give it a spin sometime next week.

[edsilv]

@markmatney @nicolasfranck did you get a chance to test your manifests using the codesandbox above?

[markmatney]

I have not yet, but I will before the end of this week.

[nicolasfranck]

@stephenwf yes it works! Weird, I build the last version of the master branch, because I found some recent changes about authentication from you, but that didn't work.. Some other branch you're using?

[markmatney]

Okay, I've had a chance to review this again. I'm not able to get auth to work as expected with the codesandbox instance and my test manifest, but I'm not sure that it's not due to additional variables introduced by codesandbox. In order to evaluate this properly I'd want to use a local instance of UV. Which branch should we be looking at? v4.0.9?

[stephenwf]

Here is the PR to check out.

[markmatney]

For the canvas in question (labeled "tiered", with the "kiosk" auth pattern specified in the image resource's info.json), the access cookie service still does not seem to be called. I've ruled out my browser configuration as the cause, since Mirador is able to open the access cookie service in a pop-up window.

Could you confirm that this is the behavior you're seeing too, by looking at my fork of the codesandbox instance? (The only difference is the manifest URL.) I would expect navigation to the aforementioned "tiered" canvas to result in the access cookie service being opened.

[edsilv]

test manifest: https://iiif-auth1.herokuapp.com/manifest/05_external

[edsilv]

Have been looking at this today and there were a few reasons why the kiosk pattern wasn't getting invoked. However, now that it's opening the token service using for example https://test.auth.iiif.library.ucla.edu/token?messageId=1676917265818&origin=http://localhost:8080 I'm getting this error back:

Does anyone have any idea what this might mean?

[markmatney]

That means that an access cookie was missing from the request to the token service.

Side note: we should probably change our server implementation to include the optional description of the error.

[edsilv]

The cookie is being set:

But it's not being sent to the token service:

[markmatney]

Sorry, slight oversight on my part: I'm guessing that you were seeing this issue, which we fixed a while back but that hadn't been deployed. It is now; can you delete the old iiif-access cookie and try again?

[edsilv]

I think this is nearly working. The auth dialogue is being displayed and the cookie is being set on close. The access token is being generated, stored, and passed.

However, on subsequent loads of the content it's showing the auth dialogue again instead of accepting the stored access token.

Here's the token being passed:

When the xhr loads, uri and dataUri don't match, which is causing the status to be set to MOVED_TEMPORARILY (302).

Could this be something on your end?

[edsilv]

https://github.com/IIIF-Commons/manifold/blob/master/src/ExternalResource.ts#L515

[markmatney]

The authentication check applied to the resource on the "tiered" canvas is based on IP address, so in order for you to render the full image when viewing that canvas, we'd have to add a subnet containing your IP address to our auth server configuration, so that you can obtain an appropriate access cookie.

The info that determines whether or not a user is granted access is encrypted in the access cookie, but is represented unencrypted in the access token:

$ echo "eyJ2ZXJzaW9uIjoiMC4wLjgiLCJjYW1wdXNOZXR3b3JrIjpmYWxzZX0=" | base64 --decode
{"version":"0.0.8","campusNetwork":false}

Also, we have currently configured the access cookie window to require user interaction to close it, but only because we figured this would be easier for debugging. It can be configured on our end to close immediately, or to close after any number of seconds.

[markmatney]

So for an access cookie obtained from outside the configured allowlist, the XHR for the info.json consistently resulting in HTTP 302 is what I'd expect.

[ksclarke]

With the latest updates, we can see our sample manifest working. The one remaining issue that we're aware of is that the tiered image access process requires user interaction (clicking a login button). The specification says, though, that in kiosk mode no user interaction should be required:

https://iiif.io/api/auth/1.0/#service-description (for the Kiosk mode):

• The user will not be required to interact with an authentication system, the client is expected to use the access cookie service automatically.

https://iiif.io/api/auth/1.0/#kiosk-interaction-pattern:

• There is no user interaction before opening the access cookie service URI
• The client must immediately open the URI from @id with the added origin query parameter

Currently, the implementation has a yellow bar iframe with a login button that must be clicked to see the full-resolution image from a tiered image. We talked in the UV SG meeting and noted that the spec suggests this be a pop-up and that this is how Mirador has implemented it as well (their implementation doesn't require user interaction).

The screenshot below shows the yellow bar:

We talked in the UV SG meeting about you looking into this on the 28th/29th to see if this additional step could be removed. Thanks!

[edsilv]

I've pushed a fix to https://universalviewer.dev - should be working without the information bar now

[ksclarke]

Thanks, @edsilv. Looks good.

[markmatney]

+1 thank you @edsilv !

[ksclarke]

I'm not sure how the project handles tickets... should this be closed by us or are there still processes on your end that need to be completed?

[edsilv]

I need to merge this to main

[ksclarke]

@edsilv Do you have a timeline on this? Thanks.

[edsilv]

builds are failing: https://github.com/UniversalViewer/universalviewer/actions/runs/5088025820 @stephenwf

[edsilv]

That's v4.0.21 published

[LlGC-szw]

All issues will be triaged for further investigation or closure by the 28 September 2023. If your issue is still relevant and would like for it be investigated further please comment by 14 September 2023.