-
-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UV does not call access cookie service for "tiered access" image that specifies Kiosk interaction #860
Comments
Same here, both for v2 and v3 manifests:
instead of seeing a dialog saying that you have to login, you are presented with a small dialog saying After debugging I found out that it is stalling at |
Besides, that |
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. |
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/). |
Thanks @stephenwf -- I should be able to give it a spin sometime next week. |
@markmatney @nicolasfranck did you get a chance to test your manifests using the codesandbox above? |
I have not yet, but I will before the end of this week. |
@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? |
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? |
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. |
test manifest: https://iiif-auth1.herokuapp.com/manifest/05_external |
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 Does anyone have any idea what this might mean? |
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. |
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 |
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, Could this be something on your end? |
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. |
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. |
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):
https://iiif.io/api/auth/1.0/#kiosk-interaction-pattern:
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! |
I've pushed a fix to https://universalviewer.dev - should be working without the information bar now |
Thanks, @edsilv. Looks good. |
+1 thank you @edsilv ! |
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? |
I need to merge this to main |
@edsilv Do you have a timeline on this? Thanks. |
builds are failing: https://github.com/UniversalViewer/universalviewer/actions/runs/5088025820 |
That's v4.0.21 published |
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. |
UV version:
I'm submitting a:
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:
Other information:
May be worth comparing with Mirador 3's implementation, which works as expected.
The text was updated successfully, but these errors were encountered: