fix: possible locally fair dataset download fix

[srmanda-cs]

What this PR does / why we need it:
Fixes the locally FAIR dataset download issue outlined in #12579 that prevents dataset files within a locally FAIR dataverse from being downloaded

Which issue(s) this PR closes:

• Closes UI Downloads do not work in datasets with a locally FAIR enabled Dataverse #12579

Special notes for your reviewer:
N/A

Suggestions on how to test this:
Spin up a docker container on develop, verify that dataset downloads don't work. Spin up this branch and verify that dataset downloads start working once again

Does this PR introduce a user interface change? If mockups are available, please link/include them here:
N/A

Is there a release notes update needed for this change?:
N/A

Additional documentation:
N/A

[Copilot]

Pull request overview

Fixes a UI download failure (404) for files in datasets under a Locally FAIR-enabled Dataverse by ensuring Locally FAIR visibility checks are performed with the session-backed DataverseRequest rather than a GuestUser request derived from the JAX-RS ContainerRequestContext.

Changes:

• Adjust findDataFileUserCanSeeOrDieWrapper to swap in dvRequestService.getDataverseRequest() when the incoming request user is GuestUser.
• Ensures Locally FAIR access checks in AbstractApiBean.findDataFileUserCanSeeOrDie(...) receive an authenticated/session user where applicable, preventing false “not found” outcomes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[srmanda-cs]

Pending IQSS team review and suggestions.

[qqmyers]

The fix takes the right approach, but I think this is too broad, as it affects all APIs and is essentially the same as https://guides.dataverse.org/en/latest/installation/config.html#dataverse-feature-api-session-auth, with the same risk noted in the Guides. (Nominally a work-around for testing LFAIR though). The access apis are special in that they are the only ones called from the JSF UI directly, so we need to allow session auth just for them even when the flag is off. This is currently being handled in a few related Access methods - see

dataverse/src/main/java/edu/harvard/iq/dataverse/api/Access.java

Lines 2284 to 2299 in 0a49c4c

	// checkAuthorization is a convenience method; it calls the boolean method
	// isAccessAuthorized(), the actual workhorse, and throws a 403 exception if not.
	private void checkAuthorization(User initialUser, DataFile df) throws WebApplicationException {
	User user = getRequestor(initialUser);
	if (!isAccessAuthorized(user, df)) {
	throw new ForbiddenException();
	}
	}
	private User getRequestor(User user) {
	// CompoundAuthMechanism should find the user by API Key/Token, Workflow, etc. And for SPA the Bearer Token
	// For JSF check if CompoundAuthMechanism couldn't find the user then try to get it from the session
	if (session!=null && user instanceof GuestUser) {
	user = session.getUser();
	}
	return user;
	}

and

dataverse/src/main/java/edu/harvard/iq/dataverse/api/Access.java

Lines 2237 to 2268 in 0a49c4c

	private boolean checkGuestbookRequiredResponse(User user, UriInfo uriInfo, DataFile df, String gbrids) throws WebApplicationException {
	// Check if guestbook response is required
	Dataset d = df.getOwner();
	boolean required = df.getOwner().hasEnabledGuestbook() && !d.getEffectiveGuestbookEntryAtRequest();
	boolean wasWrittenInPost = false;
	if (required) {
	User requestor = getRequestor(user);
	if (requestor instanceof AuthenticatedUser && permissionService.userOn(requestor, df.getOwner()).has(Permission.EditDataset)) {
	required = false;
	}
	// Check if we are downloading a thumbnail image which doesn't require a guestbook response
	boolean imageThumb = uriInfo.getQueryParameters().containsKey("imageThumb");
	if (imageThumb) {
	required = false;
	}
	if (required && gbrids != null && !gbrids.isEmpty()) {
	try {
	// verify that this id is good
	GuestbookResponse gbr = guestbookResponseService.findById(Long.valueOf(gbrids));
	if (gbr == null) {
	throw new NotFoundException("GuestbookResponse Not Found for id:" + gbrids);
	}
	Long delta = Instant.now().toEpochMilli() - gbr.getResponseTime().getTime();
	wasWrittenInPost = gbr.getDataset().getId().equals(df.getOwner().getId()) && delta <= (GUESTBOOK_RESPONSE_SIGNEDURL_TIMEOUT_MINUTES * 60000L);
	} catch (NumberFormatException | DateTimeParseException ex) {
	throw new BadRequestException(ex.getMessage());
	}
	}
	}
	return required && !wasWrittenInPost;
	}

, which are known to have bugs related to privateUrl users - see #12569, #12548, etc. There is also a PR coming that shuffles a lot of this code #12479.

We probably need to discuss this more, but I might suggest we simplify by just exempting the access apis in https://github.com/IQSS/dataverse/blob/develop/src/main/java/edu/harvard/iq/dataverse/api/auth/SessionCookieAuthMechanism.java which should resolve this issue, and the private URL one and clean up the code. I'll put this in triage so this gets on the radar Monday.

[srmanda-cs]

Thanks for the detailed review and context!

My original fix was definitely intended as a minimal proof-of-concept to get the root cause and a workaround on the team's radar.

Your suggestion to handle this at the SessionCookieAuthMechanism level makes a lot of sense. I am happy to pause or close this PR and let the team discuss the best path forward.

[donsizemore]

may also close #12563