On 22 Dec 2011, at 02:22, Brian Burch <[email protected]> wrote: > On 22/12/11 06:39, Jerry Malcolm wrote: >> About a month ago, I upgraded two different servers from TC 5 to TC 7. The >> migration went cleanly, and everything has been working fine with the >> exception of one thing. About 50% of the time, when I log in to the realm >> for my web app (form-based login), the login will fail. When I try again >> with the same id/pw it works. I can then log out and log back in >> repeatedly with no problem. But if I come back later and try to log on >> again, same things. Fails once, and then passes. >> >> My authentication configuration hasn't changed for years on these webapps, >> and this has worked solid on TC 5. My database (MySQL) hasn't changed, and >> the user tables are unchanged. The only thing that has changed is TC 5- >> -->TC 7. And the problem has hit both servers, completely independent of >> each other, other than they both got the TC 7 upgrade. >> >> First of all, has anyone ever heard of this situation? Second, any idea >> how where/how to turn on detailed tracing/logging of the authentication >> calls to see what might be going on in the authentication code in TC? The >> only information I'm getting is that the id/pw were not correct. But >> again, same id/pw becomes correct when I submit it a 2nd time. >> >> The one thing I didn't change was the MySQL connector. Should that have >> been changed for TC 7? (Just guessing now) >> >> Suggestions for how to proceed? >> >> Thx. >> >> Jerry >> > > When I was working on a NonLoginAuthenticator problem with the SingleSignOn > Valve, I noticed behaviour similar to that described when interacting with > FormAuthenticator. > > I didn't want to get side-tracked from my primary problem, so I didn't > investigate it thoroughly. I also have a bad memory, but I /think/ I remember > the symptoms were caused by the browser sending an SSO cookie associated with > a session which had previously expired. The login failure was because the > FormAuthenticator did not handle this situation gracefully. As you > discovered, the second attempt is successful because the SingleSignOn Valve > deletes the expired cookie as part of the initial error response. This means > the second login attempt proceeds without the browser sending any SSO cookies > and so starts again "from scratch". > > Of course, if you haven't enabled SSO, then all the above is narrative is > irrelevant! On the other hand, if you have enabled SSO, then you can confirm > my theory with either a wireshark trace, or by turning on debug logging for > SSO and FormAuthenticator - both classes provide detailed logging, but it > isn't very helpful unless you understand the logic flow and interactions > between these two classes. > > I think it should be possible to make the handling of expired SSO cookies > more more graceful, i.e. bounce directly back to the login form rather than > display the error response.
That's interesting. I don't think reverting to the login page after form submission will fly, but maybe a bad SSO cookie could be handled better. Reproducible? p > However, if only you and me care about it, then I have more important things > to work on! > > Regards, > > Brian > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
