Repository navigation
fix(iiif): give access tokens only to viewers the person confirmed - #160
Merged
Merged
Conversation
With iiif.allowed_origins at its default (*), any site could load the token service in a hidden iframe and get an access token for whoever was signed in to the IIIF access page. The access cookie now remembers the viewers the person signed in for or confirmed with Continue, and the token service answers only those. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01W42z4FbekWr33b6791svQQ
Owner
Author
|
Local CI: green. The self-hosted runner is down, so I replayed every PR job from Local CI on PR #160 head 5ab1751 merged into main f69d6af, 2026-10-05 07:27 UTC
Generated by Claude Code |
…-qt650x-iiif-origins # Conflicts: # fastapi_backend/tests/api/test_iiif.py
This file contains hidden or 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
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.
Requested by Adeel · project thread
Description
Before:
iiif.allowed_originsdefaults to*and the IIIF access cookie isSameSite=None. Once someone signed in on the IIIF access page for one viewer, any website they visited could load/iiif/auth/tokenin a hidden iframe and receive an access token for their account. With that token it could probe and play every restricted recording the person could open.After: the access cookie remembers which viewer sites the person signed in for, or confirmed with Continue on the access page (the page already names the site that is asking). The token service gives tokens only to those sites. Any other site gets the spec's
missingAspecterror, so a compliant viewer opens the access page and the person decides. Theallowed_originssetting and its default are unchanged.Motivation and Context
This came from the threat model's surface pass. Users will see one difference: a second viewer site now needs one Continue click before it can play restricted recordings. IIIF cookies issued before this change carry no confirmed sites, so the first token request after upgrading asks for Continue once.
Steps to reproduce (if appropriate):
test_tokens_go_only_to_viewers_the_person_signed_in_forsigns in forhttps://viewer.exampleand then asks for a token ashttps://evil.example. On main, the second site got a token. With this change it getsmissingAspectuntil Continue is pressed. One line of the existing flow test now passes the viewer's origin when signing in, as IIIF viewers do.Types of changes
!in the title)Checklist:
make hookschecks it on commit).docs/accordingly.## UnreleasedinCHANGELOG.md.🤖 Generated with Claude Code
https://claude.ai/code/session_01W42z4FbekWr33b6791svQQ
Generated by Claude Code