1. A bug. Confused usage of local (method) variable and instance field with the same name "authenticated".
2. Unexpected / strange response from JNDI. Again, this is a non-existent user with no password provided. In the case seen in the log, JNDI does not throw an exception. I haven't seen any documentation on what to expect in this case, and certainly didn't expect this behavior for the specific case of no password provided. In local testing, I've seen exceptions thrown always on no password provided. The difference could be due to the directory server used, I guess. I've changed the code defensively, but need to test before sending the patch. I will also both
(a) trap the lack of password in the Fedora code itself, so that it's an error to Fedora before JNDI is called; and
(b) treat empty results returned from the results as non-authentication.
Both of these will be configurable, which will allow further testing if we want/need to tease this out (i.e., ferret out when exceptions are unexpectedly not thrown).
3. A bug. The cached authentication value is not reset before the re-authentication attempt. A re-authentication attempt with exception thrown then results in using the existing cached value. This is puzzling especially when the the cached value is --incorrectly-- set to true, as set in the second login attempt with no password and no exception thrown by JNDI. That is, case 3 (or 4) is the result of both this bug --and-- case (2) having incorrectly cached a true authentication value. Strange case and inadequate testing.