Possible race condition problem in login process?
Locked
Possible race condition problem in login process?
 
|
Re: Possible race condition problem in login process?
|
|
Re: Possible race condition problem in login process?
|
|
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 >> USER_LOGIN_HISTORY is inserted into twice for any ONE login attempt? >> 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 > |
smime.p7s (3K)
Re: Possible race condition problem in login process?
|
|
Re: Possible race condition problem in login process?
|
|
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 > after revs 532993 and 532994 even with my modifications there are > still this > 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 <[hidden email]>: >> >> >> 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 >> >> USER_LOGIN_HISTORY is inserted into twice for any ONE login >> attempt? >> >> 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 >> > >> >> >> |
Re: Possible race condition problem in login process?
|
|
Re: Possible race condition problem in login process?
|
|
I guess what I'm looking for is what do you do to make this problem happen? You mentioned a login twice in one second, but how do you do that? -David On Apr 27, 2007, at 2:45 PM, Krzysztof Podejma wrote: > MySQL and firefox with savet login and password > try to login twice in a one second and You will get this error in > console: > (Duplicate entry 'admin-10011-2007-04-27 22:43:31' for key 1))). > Rolling > back transaction. > > Krzysztof Podejma > > 2007/4/27, David E. Jones <[hidden email]>: >> >> >> 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 >> > after revs 532993 and 532994 even with my modifications there are >> > still this >> > 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 <[hidden email]>: >> >> >> >> >> >> 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 >> >> >> USER_LOGIN_HISTORY is inserted into twice for any ONE login >> >> attempt? >> >> >> 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 >> >> > >> >> >> >> >> >> >> >> >> |
Re: Possible race condition problem in login process?
|
|
Re: Possible race condition problem in login process?
|
|
The real problem that I'm hoping to solve is why is OFBiz trying to create two UserLoginHistory records within one second in the first place? There is something not right there... -David On Apr 27, 2007, at 2:57 PM, Krzysztof Podejma wrote: > go to party manager click logout (upper right corner), click login > in the > middle, then logout (upper right), and login > if You don't get error try it several times > > i think it is mysql timestamp issue, derby has milliseconds in > timestamps, > mysql not. > see my comment in jira > > Krzysztof Podejma > > 2007/4/27, David E. Jones <[hidden email]>: >> >> >> I guess what I'm looking for is what do you do to make this problem >> happen? You mentioned a login twice in one second, but how do you do >> that? >> >> -David >> >> >> On Apr 27, 2007, at 2:45 PM, Krzysztof Podejma wrote: >> >> > MySQL and firefox with savet login and password >> > try to login twice in a one second and You will get this error in >> > console: >> > (Duplicate entry 'admin-10011-2007-04-27 22:43:31' for key 1))). >> > Rolling >> > back transaction. >> > >> > Krzysztof Podejma >> > >> > 2007/4/27, David E. Jones <[hidden email]>: >> >> >> >> >> >> 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 >> >> > after revs 532993 and 532994 even with my modifications there >> are >> >> > still this >> >> > 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 <[hidden email]>: >> >> >> >> >> >> >> >> >> 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 >> >> >> >> USER_LOGIN_HISTORY is inserted into twice for any ONE login >> >> >> attempt? >> >> >> >> 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 >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> |
| Free forum by Nabble | Edit this page |