Display restricted to staff #11302
Merged
Display restricted to staff #11302
+124
−79
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
… v2 external service
|
Size Change: +2.77 kB (+0.28%) Total Size: 973 kB
ℹ️ View Unchanged
|
rcantin-w
reviewed
Oct 23, 2024
rcantin-w
reviewed
Oct 23, 2024
| @@ -30,6 +30,7 @@ type Props = { | |||
| parentManifest: ParentManifest | undefined; | |||
| searchResults: SearchResults | null; | |||
| setSearchResults: (v) => void; | |||
| accessToken: string | undefined; | |||
There was a problem hiding this comment.
np: below we use the prop?: string form, we could align? very much not a blocker or necessary.
rcantin-w
reviewed
Oct 23, 2024
| const mainImageService = { '@id': currentCanvas.imageServiceId }; | ||
| const urlTemplateMain = mainImageService['@id'] | ||
| ? iiifImageTemplate(mainImageService['@id']) | ||
| const { user } = useUser(); |
There was a problem hiding this comment.
Not a real suggestion for this just a thought; was wondering if it was worth adding something like
const isStaffWithRestricted = user?.role === 'StaffWithRestricted'
in the useUser() context/hook. Since we do this check often!
rcantin-w
approved these changes
Oct 23, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this change?
Makes restricted items viewable on the item page for users with a role of 'StaffWithRestricted'. For #5761
N.B. It does not deal with born digital things, which we list on the works page. - this needs further consideration.
Things to be aware of:
The IIIF Authorization Flow API 2.0 docs describe three interaction patterns external, kiosk and active. Kiosk is not relevant to us. Active is what we currently use for the clickthrough, but could be used to offer a login. External is the profile used for restricted items.
We use external for restricted items because we don't want to present most users with a login when they either don't have an account, or if they do, their account doesn't give them access to restricted items anyway. This is also the preferred behaviour if the iiif manifest were to be loaded into a third party viewer.
Ordinarily, with the external access service:
and
However, in our case there is an access service provided by the id of the external service and we need to use it because logging in via Auth0 is a separate system and doesn't provide the authorizing aspect we need.
How we handle restricted items using the external service
The IIIF Authorization Flow API 2.0 docs then states we should use query the Probe service with the access token to understand whether the user has access to the access-controlled resource for which the probe service is declared. Orignally I did this, but the probe service doesn't return anything other than a 200 status in our case, so it felt a bit redundant. Instead, I simply use the presence of the accessToken as the condition for trying to load the images.
Other things worth knowing
We can have v2 and v1 versions of the auth services in a manifest, but we don't always have v2. Furthermore, only the access service provided by the id of the v2 exteranl service works, the v1 version 404s.
We therefore always try to use the v2 service and fallback to the v1 service. We need to fallback because the presence of this service is what we use to determine whether to show the restricted message to users.
This means that if a user is logged in with a role of 'StaffWithRestricted' and visits an items page with restricted things but only v1 auth services in the manifest, the images won't load. There is a ticket to address this with modified messaging. Caveat if the user has already visited an item with v2 external services and authorized, then they will be able to see the images.
The iiif docs state that, "If more than one access service is available, the client should interact with them in the order external, kiosk, active." However, in our case we only want users with a role of "StaffWithRestricted" to use the external access service and only if the external access service is available as v2.
Because the external access service only works with v2 services, we fallback to the v1 active service (if we have a mix)
This means that, for items with a mix of external and active services, users with roles of "StaffWithRestricted" will still be able to see things that require a user interaction.
How to test
The behaviour should be the same as the live site.
N.B. users should never end up in the above situations as we don't link to the items page from the work page under these circumstances.
N.B. on local a new window should open either with a login form or a submit button. Once the form is submitted or the button clicked the window should close.
N.B. Restricted PDFs should behave as audio/video do. However, according to Ashley all PDFs that are ingested are open, so we can't test them.
How can we measure success?
Staff with the correct permissions can view restricted material.
Have we considered potential risks?
Risks should be negligible as the only changes in behaviour should be for the limited number of people who have the role of 'StaffWithRestricted'. As long as e2e tests are passing and the above testing works, we should be good.