Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [servlet-dev] [cu-dev] TCK - context-related behavior of HttpServletRequest.getUserPrincipal()
Hi,

Practically speaking, the principal should be the one acquired from an internal "security context", which is almost always something in thread local storage (for the current request). It's possible to logout mid-request (which clears the principal) and also possible to authenticate mid-request again (by calling request.authenticate). A principal is always set for at most the duration of a request. If a longer period is required (using the HTTP session), an authentication mechanism has to set it for every request again explicitly.

I think the issue here is not whether a request instance caches the principal or not internally, but whether a request instance can actually be shared between threads this way. I don't think this is the case. You have to use AsyncContext asyncContext = request.startAsync();

Btw, the Servlet Container Profile of Jakarta Authentication essentially clarifies the Servlet behaviour in a Jakarta EE container, and can sometimes be used to get some questions answered. Unfortunately due to historic reasons we have this overlap of the same things being defined in Servlet itself, and in the Servlet Container Profile of Jakarta Authentication. 

Kind regards,
Arjan Tijms


On Tue, Apr 19, 2022 at 9:18 PM Nathan Rauh <nathan.rauh@xxxxxxxxxx> wrote:

Looking over the JavaDoc for getUserPrincipal, it isn’t clear to me which behavior is correct (caching or not caching).

In one place it says, “Returns a java.security.Principal object containing the name of the current authenticated user” and in another place states, “Returns: a java.security.Principal containing the name of the user making this request”.  The former sounds like there should be no caching because it says current user, and the latter sounds like caching because it’s tied to the requesting user, not current user.

 

This lack of clarity is in the Servlet spec, and it is not the place of the Concurrency TCK to interpret and force a particular behavior for Servlet.  I’ll get a pull created to disable those two tests.  Thanks for spotting this!

 

 

From: cu-dev <cu-dev-bounces@xxxxxxxxxxx> on behalf of Petr Aubrecht <aubrecht@xxxxxxxxxxxx>
Reply-To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Date: Tuesday, April 19, 2022 at 1:36 PM
To: cu developer discussions <cu-dev@xxxxxxxxxxx>
Subject: [EXTERNAL] [cu-dev] TCK - context-related behavior of HttpServletRequest.getUserPrincipal()

 

Hello again, I'm trying to go through the remaining context-related issues. One of them is the security behavior, test ContextPropagationTests.testSecurityUnchangedContext. The key piece of code is this: ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ‍ ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hello again,

I'm trying to go through the remaining context-related issues.

One of them is the security behavior, test ContextPropagationTests.testSecurityUnchangedContext. The key piece of code is this:

ManagedExecutorService executor = InitialContext.doLookup("java:app/concurrent/executor2");
 
CompletableFuture<String> future = executor.supplyAsync(() -> {
 
    // Security Context should not be available for calls on a new thread
 
    return request.getUserPrincipal() == null ? "null" : request.getUserPrincipal().getName();
 
});
 

 

The executor is configured with context, which has attribute unchanged = SECURITY.

The request variable is shared from the calling function, and the security is stored directly in the request object. Then it fails, as the getUserPrincipal() returns the remembered value, not the contextual.

 

My question: is it required, that request.getUserPrincipal() calls the contextual value and it must not cache it?

Is it something new in the current version of Servlet API? I haven't found anything related in Servlet API 6.0.

 

The same problem is with testSecurityClearedContext (cleared security).

Thank you

Petr

_______________________________________________
cu-dev mailing list
cu-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cu-dev

Back to the top