Bugfix - Work page public items requiring auth on initial load - #494
Merged
Conversation
kdid
force-pushed
the
5826-work-page-access
branch
from
August 5, 2026 17:16
7a51db4 to
0f9e227
Compare
mbklein
approved these changes
Aug 5, 2026
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.
Summary
Fixes intermittent "Authentication needed" banners on public work pages, embedded viewers, and the download/embed dialog. This was a gap left by #488/#489: those PRs fixed the same race condition for search result thumbnails but never touched the work-detail page, which had its own copy of the login-required logic. Also, that merged work dropped the
!isAuthLoadingguard, so the work page regressed.Public, published works now render immediately regardless of auth state, matching the guarantee #489 gave search results. Non-public works now render neither the viewer nor the restricted banner until auth has actually resolved, which also fixes a potential reverse flash (a NetID user opening an Institution work could briefly see "Authentication needed" before the viewer swaps in).
fixes https://github.com/nulib/repodev_planning_and_docs/issues/5826
Changes
hooks/useWorkAuth.ts— added aisWorkPublic && work.publishedshort-circuit touserCanRead, independent of auth/user state; added a sharedloginRequired(work && !userCanRead && !isAuthLoading) so restricted status is only asserted once auth has resolved; guardedscopes.includeswith optional chaining so a malformedwhoamipayload can't throw during renderpages/items/[...id].tsx— consumeloginRequiredfrom the hook instead of a local copy of the expressioncomponents/Work/EmbeddedViewer.tsx— accepts aloginRequiredprop instead of computing it fromisAuthLoadingpages/embedded-viewer/[manifestId].tsx— passesloginRequiredfrom the hook down toEmbeddedViewercomponents/Work/ActionsDialog/DownloadAndShare/EmbedResources.tsx— derives its "Download requires NetID" announcement from the hook'sloginRequired, still exempting shared-link pageshooks/useWorkAuth.test.ts(new) — covers public+published during auth load, public with a failed/emptywhoami, public-but-unpublished, non-public during load, non-public with/without matching scope, and a malformed user payloadcomponents/Work/EmbeddedViewer.test.tsx— updated for the prop change; added a case for the non-public/loading render-nothing stateTesting
dcapi*cookie forlibrary.northwestern.edu(12h TTL) and hard-reload a public work page — viewer should render with no banner (- or use Incognito mode)/auth/whoamiin DevTools to make the race reproducible; confirm no banner flash on a public work/embedded-viewer/[manifestId]for a public work, and the Download and Share dialog on a public work and a/shared/[id]link