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!
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