Repository navigation
fix(iiif): refuse password sign-in on the access page when passwords are off - #158
Merged
Merged
Conversation
…are off The IIIF access service signed people in with a password even with auth.passwords off. It now shows no password form there, and a submitted one answers 403, as the rest of the API does. 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 #158 head 516fad2 merged into main f69d6af, 2026-10-05 07:56 UTC
Generated by Claude Code |
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: with password sign-in turned off (
auth.passwords), the IIIF access page at/iiif/auth/accessstill showed a password form, and submitting it signed the person in and set the IIIF cookie.After: with passwords off, the page explains that it can't sign anyone in yet and shows no form. A submitted password answers 403 and sets no cookie. Installs with passwords on behave as before.
Motivation and Context
This came from the threat model's surface pass (
api/iiif.py, POST handler). docs/authentication.md says that with passwords off, password sign-in answers 403. The/api/v1/auth/loginroute did that, but the IIIF form calledauth.logindirectly and skipped the check. Passkey sign-in on this page is not built, so third-party viewers on such installs play only open material. docs/iiif.md now says so.Steps to reproduce (if appropriate):
test_access_form_refuses_passwords_when_they_are_offfailed on main with 200 (signed in) instead of 403, and passes with this change.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