Update: I found out that a subsequent fetch of 'ui/sw.js' from login.js triggers the new authentication that mixes up the login page.
Sorry to resurrect this old thread of mine, but I still got this problem. The order in the authenticationChain is just like you described. I even tested it the other way around (just a sanity check).
I can confirm this works as it should when using the REST API.
But for the Web UI in the browser, it's a different story.
Digging through debug logs and the NuxeoAuthenticationFilter code my guess is this:
- logging out correctly invalidates the cachableUserIdent and redirects to /ui with
forceAnonymousLogin=true
forceAnonymousLogin forces a redirect to login.jsp- login.jsp shows the form for username and password
BUT before I even type in my credentials I can see in the logs that I am authenticated as anonymous user.
In the next step (submitting the form) this bypasses the "Authentication Filter" with "userIdent found in cache, get the Principal from it without reloggin"
So something in between logging out and showing login.jsp triggers authentication (which succeeds because of ANONYMOUS_AUTH) and prevents the credentials from being used after all.
Sidenote: When I am on the login.jsp page and remove the JSESSIONID cookie it works. My guess is this invalidates the userIdent caching.
