9531 - Add a Log Out endpoint available when the session API auth feature flag is enabled

[GPortas]

What this PR does / why we need it

New Log Out endpoint

Only available when the Session Auth feature flag is enabled

Initially, to emulate the JSF Log Out feature in the SPA, we considered the option of removing the JSESSIONID session cookie from the React application code, by accessing the browser cookies using a cookie management library. This solution would have the trade-off of not terminating the session in the backend, as JSF does when clicking log out, but considering the temporary lifetime of the session based API authentication, and that it will be executed on a closed and small beta testing environment, we did not find it a bad solution.

The problem with the previous solution and what makes it unfeasible is that the JSESSIONID cookie is HttpOnly, which means that it cannot be read or managed from javascript code. This has forced us to have to enable an endpoint to perform the Log Out.

Although the endpoint is publicly exposed, it only works when the feature flag is enabled, returning a server error otherwise. When the API evolves towards the final authentication mechanism, the logic of this endpoint will be modified to make it standard for all authentication mechanisms subject to Log Out (API Key is not subject to Log Out).

Which issue(s) this PR closes

• Closes Add a Log Out endpoint available when the session API auth feature flag is enabled #9531

Special notes for your reviewer

This PR is part of an end-to-end flow that covers three PRs from three different repositories:

• 53 - Add Login / Logout dataverse-frontend#67
• 56 - Add use cases to get the current authenticated user and log out dataverse-client-javascript#57

Suggestions on how to test this

Feature flag disabled curl test

1. Deploy Dataverse with this branch without modifying the MicroProfile Config properties
2. Once deployed, log in and get the associated session cookie from the browser
3. Try to log out from the API by sending the cookie manually curl --cookie "JSESSIONID=<YOUR_COOKIE>" -X POST http://localhost:8080/api/v1/logout
4. The operation should return an error indicating that the feature flag is disabled

Feature flag enabled curl test

1. Enable the feature flag: dataverse.feature.api-session-auth=true
2. Re-deploy Dataverse
3. Once deployed, log in and get the associated session cookie from the browser
4. Try to log out from the API by sending the cookie manually curl --cookie "JSESSIONID=<YOUR_COOKIE>" -X POST http://localhost:8080/api/v1/logout
5. The operation should indicate that the user is logged out.
6. Refresh JSF page, and check that the user is logged out.

Real end-to-end test

Test the end-to-end flow following the frontend repository PR instructions:

• 53 - Add Login / Logout dataverse-frontend#67

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

No

Is there a release notes update needed for this change?

Not sure

Additional documentation

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Credentials

[pdurbin]

I have questions. Here's some initial feedback.

[pdurbin]

Can we keep...

((HttpServletResponse) sr1).addHeader("Access-Control-Allow-Origin", "*");

... everywhere instead of changing it from * to frontendOrigin in some cases? I fear something will break.

:AllowCors is "true" by default, which means * - https://guides.dataverse.org/en/5.13/installation/config.html#allowcors

I'm wondering if we can do something like this (untested) instead:

if (settingsSvc.isTrueForKey(SettingsServiceBean.Key.AllowCors, true )) {
    ((HttpServletResponse) sr1).addHeader("Access-Control-Allow-Credentials", "*");
    ((HttpServletResponse) sr1).addHeader("Access-Control-Allow-Methods", "PUT, GET, POST, DELETE, OPTIONS");
    ((HttpServletResponse) sr1).addHeader("Access-Control-Allow-Headers", "Accept, Content-Type, X-Dataverse-Key, Range");
    ((HttpServletResponse) sr1).addHeader("Access-Control-Expose-Headers", "Accept-Ranges, Content-Range, Content-Encoding");
}
if (FeatureFlags.API_SESSION_AUTH.enabled()) {
    ((HttpServletResponse) sr1).addHeader("Access-Control-Allow-Credentials", "true");
}

Now that I look at the PR description, I see this:

"On the other hand, a specific URL value for "Access-Control-Allow-Origin" is established (Loaded from a MicroProfile property), replacing the wildcard "*", which is not supported when Access-Control-Allow-Credentials is enabled."

So I guess it was done this way for a reason. I still worry something will break though, since * is the out of the box default. 🤔

The new header really doesn't work with *?

[qqmyers]

FWIW: Here's the discussion about CORS on the bucket for previewers to use direct download: https://github.com/gdcc/dataverse-previewers/wiki/Using-Previewers-with-download-redirects-from-S3 . For the buckets, we found that dropping AllowedOrigin from '*' causes trouble - https://github.com/gdcc/dataverse-previewers/wiki/Using-Previewers-with-download-redirects-from-S3#if-you-are-interested-in-restricting-the-allowedorigins-and-allowedheaders is as far as I got towards a solution.

The previewer info may be out of date or irrelevant but I'd ask/say:

• do you need to worry about bucket rules as well?
• if the change is on all the time, please check to see that hosted previewers work with your fix, and
• if you find a better solution, perhaps we can update the previewer docs as well.

[pdurbin]

Yep, remote previewers need CORS. I started a Slack thread to discuss this further: https://iqss.slack.com/archives/C04EE66HW2Y/p1682524744005719

[poikilotherm]

Question: is it necessary to create another scope and do you expect more settings to be added here? From the docs and descriptions I understand this URL is only used for CORS so far, so maybe we could move this to the API scope?

[qqmyers]

Should this setting be front-end-specific at all? If someone creates another client, would this need to be more than one url? I.e. should this be named something like ALLOWED_CORS_ORIGINS with a value that is a list of urls, defaulting perhaps to just the front end url?

[poikilotherm]

This sounds reasonable (and is easy to apprehend with the lookup function, just give it the String[].class as parameter...)

Should this include migrating :AllowCors to a or this JvmSetting? The list could default to "*" as was discussed above. (And probably there is no need for backward compatibility for a DB setting that defaulted to true.)

[GPortas]

@qqmyers I prefer to make it front-end specific, just for the Dataverse Frontend SPA. Making it configurable using that list of allowed origins may end up with someone turning on the feature flag to add their own clients and authenticate them via session cookie, while the only intended use case for the feature flag is SPA development. Remember the security risks and the temporary lifetime of the feature flag (It will be removed when we have a final auth mechanism).

@poikilotherm Personally I have no preference in one scope or another. I can move it to the API scope if it is clearer in that way. Ideally, I would have liked to add it to the same scope as the feature flag, because they depend on each other. But the current feature flag mechanism does not support that kind of "subproperties" (If I am not wrong.)

[mreekie]

sprint kickoff

• There are three pull requests all in a row for a total of 10.

[pdurbin]

@GPortas just a heads up that I went ahead and resolved merged conflicts in 25e081d

It was just a whitespace change vs some mail settings being added:

[pdurbin]

Approved. I've been testing this with the frontend PR.