Re: Possible race condition problem in login process?

[David E. Jones]

What is your test case that is failing now?

-David


On Apr 27, 2007, at 2:17 PM, Krzysztof Podejma wrote:

I showed possible workaround in
https://issues.apache.org/jira/browse/OFBIZ-925

error in console log because visitid doesn't increment anymore ...
without changes in revs 532993 and 532994 worked well

Regards
Krzysztof Podejma

2007/4/27, David E. Jones <[EMAIL PROTECTED]>:

after revs 532993 and 532994 even with my modifications there are still this

The funny logout/login problem should now be fixed (not the
underlying timestamp resolution problem, but the logout/login loop)
in revs 532993 and 532994.

-David


On Mar 16, 2007, at 9:06 AM, Jonathon -- Improov wrote:

> Found the problem. To reproduce problem:
>
> 1. Use MySQL
> 2. Enter a URL like https://<yourhost>//partymgr/control/logout
> 3. Login.
>
> I've fixed it in RequestHandler.java, preventing a "do previous
> URL" whenever the URL is "/logout". Brutish, yes, but no more
> awkward than what was in place originally.
>
> Flow that caused error:
>
> 1. Perform login, write login history.
> 2. Successful login, do previous request ("/logout" in this case)
> 3. Logged out again, auto-perform a login and write login history.
>
> If steps 1 and 3 occur within the same second, you'll get the
> error. Error occurs at the 2nd login history insert. MySQL's
> datetime types have resolution of 1 second; PostgresSQL has 1
> millisecond or maybe even microsecond.
>
> This is obviously an error, but was probably never spotted because
> PostgreSQL's 1 millisecond resolution "forgave" this error whenever
> it happened.
>
> Jonathon
>
> Jonathon -- Improov wrote:
>> I get an error message like "Duplicate entry 'admin-2007-03-12
>> 12:12:44' for key 1" when trying to login (using user login
>> 'admin'). I'm using MySQL.
>> To reproduce, simply go to say http://<yourhost>/partymgr/control/
>> login , login successfully, then logout, then go to http://
>> <yourhost>/partymgr/control/login and then immediately try to
>> login. Your username will still be in the form, so you can quickly
>> login by retyping only your password.
>> Before I dig into this, can somebody tell me if table

>> Thanks.
>> I guess those using PostgreSQL won't feel this problem, since its
>> datetime resolution is much smaller than 1 second. But can this be
>> a deeper issue with the way login is done in OFBiz?
>> Jonathon
>

>> USER_LOGIN_HISTORY is inserted into twice for any ONE login attempt?

smime.p7s
Description: S/MIME cryptographic signature