View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000197 | Main CAcert Website | certificate issuing | public | 2006-04-04 19:47 | 2013-01-14 03:12 |
| Reporter | falkinhan | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Fixed in Version | 2006 | ||||
| Summary | 0000197: in simultaneous operation of assurer and applicant, changed deta can be confirmed | ||||
| Description | - applicant was registered to the system and goes to verify his data. - at the same moment I have got his data to verify - at that moment hi changed his data. - than I finished verification of the data on my screen (unmodified), and because it has been correct, issued him points. - his date has been locked, - so finally hi is certified with wrong data and can not correct it. It will also work in simultaneous operation of number of assurers, so we can totally issue more than 50 points. | ||||
| Additional Information | I talked to Philipp Gühring and give him the following idea: In user record we can keep some kind of CRC 0f whole user record. This CRC is taken to the form, but is not editable. When I am committing data, CRC is transmitted with it and checked if is the same as stored in database. If is the same - data is committed. If not - operation is failed with the message like this: "Operation failed - data was changed - please repeat" or similar. | ||||
| Tags | No tags attached. | ||||
| Reviewed by | |||||
| Test Instructions | |||||
|
|
> - applicant was registered to the system and goes to verify his data. Verify means what? He created his account and goes to the "details" section and looks at his account details such as name, date of birth, lost password questions? > - at the same moment I have got his data to verify So he has already signed up and you want to assure him. > - at that moment hi changed his data. > - than I finished verification of the data on my screen (unmodified), > and because it has been correct, issued him points. If the users changed his name or date of birth you will get a warning talking about a "race condition" and asking you to verify the modified name/date of birth again. This check has been enabled about 9 month ago. Are you sure that you didn't received such a message? > - his date has been locked, > - so finally hi is certified with wrong data and can not correct it. I don't understand why he modified his correct data to be incorrect. And I don't understand why you didn't see the warning about the race condition. > It will also work in simultaneous operation of number of assurers, > so we can totally issue more than 50 points. Every assurer is allowed to issue 35 points. If multiple assurers assure the same person they are allowed to issue up to 100 points. This should be totally independent from the possible race condition you talked before. |
|
|
> > - applicant was registered to the system and goes to verify his data. > > Verify means what? He created his account and goes to the "details" > section and looks at his account details such as name, date of birth, lost > password questions? yes, date of birth has been changed because of wrong collaboration between website and browser. We will try to repeat it on the test system. > > > - at the same moment I have got his data to verify > > So he has already signed up and you want to assure him. > yes, I was assuring number of the people after the meeting. > If the users changed his name or date of birth you will get a warning > talking about a "race condition" and asking you to verify the modified > name/date of birth again. This check has been enabled about 9 month ago. > > Are you sure that you didn't received such a message? > 95% yes, I didn't. 5 % I have got a message, not clean, looks like a communication problem and I goes back and conformed again. > > - his date has been locked, > > - so finally hi is certified with wrong data and can not correct it. > > I don't understand why he modified his correct data to be incorrect. And I > don't understand why you didn't see the warning about the race condition. > This is probably another bug - some browsers are working bad with javascript and selectors. Additionally are fulfilling the forms with the last data and showing wrong old data. We will check it on the test system and send the report. > > It will also work in simultaneous operation of number of assurers, > > so we can totally issue more than 50 points. > > Every assurer is allowed to issue 35 points. If multiple assurers assure > the same person they are allowed to issue up to 100 points. This should be > totally independent from the possible race condition you talked before. > simultaneous operation of number of assurers is possible scenario after the events. |
|
|
> yes, date of birth has been changed because of wrong collaboration between > website and browser. We will try to repeat it on the test system. When he signed up: Was his date of birth correct? If yes: Why did he change it? If no: What data did YOU assure? Isn't it possible that you didn't see the wrong date of birth when assuring the user and issued him his points. And then the user tried to change his date of birth to the correct date and couldn't anymore? > 5 % I have got a message, not clean, looks like a communication problem > and I goes back and conformed again. "not clean" means what? Which message did you receive? People are using this interface for mass assurances after events such as CeBit or LinusTag and I don't know about problems in the communication. >> I don't understand why he modified his correct data to be incorrect. And I >> don't understand why you didn't see the warning about the race condition. > > This is probably another bug - some browsers are working bad with javascript > and selectors. Where do you need JavaScript in the signup or assurance process? Which form/selectors are you talking about? > Additionally are fulfilling the forms with the last data and > showing wrong old data. Well, if you assure someone its a feature that the form will be refilled with the same date/location/... because for people doing mass assurances this is a big help as they don't need to reinsert the same values all the time. > We will check it on the test system and send the report. Thanks. I really like to know if there is something broken. >> Every assurer is allowed to issue 35 points. If multiple assurers assure >> the same person they are allowed to issue up to 100 points. This should be >> totally independent from the possible race condition you talked before. > > simultaneous operation of number of assurers is possible scenario after > the events. Yes and it shouldn't be a problem. They can issue 35 points each up to a total number of 100. If you try do add more than that the number will be decreased: 35 + 35 + 30 + 0 + 0 + ... This function never made any problems and I see no way for a race condition. What do you mean? Can you reproduce it? |
|
|
> When he signed up: Was his date of birth correct? If yes: Why did he > change it? If no: What data did YOU assure? His date WAS CORRECT. Hi deleted second name and some how his day of birth has been changed from 27 Feb to 2 Feb. It could be problem with his browser. > "not clean" means what? Which message did you receive? Unfortunately I have hot logged the session. I have seen some messages, that it was an error with data commitment, but it looks like communication problem. In the case like this, I think it should be very clean message, for example: "APPLICANT DATA HAS BEEN CHANGED (edited). PLEASE VERIFY HIS DATA AGAIN". Another good idea is to add one more step: After fullfilling the assurance, system can display all data on the single page, w/o possibility to edit. Than assurer can cancel or confirm. Additionally time for this operation can be limited for for example 60 sec. and applicant's record can be locked for this time. I hope it will finally solve the problem. > This function never made any problems and I see no way for a race > condition. What do you mean? Can you reproduce it? Give us some time. We will try to destroy testing system ;) We will check it with diffrent browsers, also with windoza. rgds |
|
|
> His date WAS CORRECT. > Hi deleted second name and some how his day of birth has been changed > from 27 Feb to 2 Feb. Alright. So he changed his details twice? Once removing the second name and accidently changing the date of birth. Once to fix the date of birth and this was not possible anymore (because you assured him)? > It could be problem with his browser. I guess so. The old date of bith is selected using the normal html "selected" parameter. No client scripting language involved. > I have seen some messages, that it was an error with data commitment, > but it looks like communication problem. Hmmm. > In the case like this, I think it should be very clean message, > for example: "APPLICANT DATA HAS BEEN CHANGED (edited). PLEASE VERIFY HIS > DATA AGAIN". What about "Race condition discovered, user altered details during assurance procedure. PLEASE MAKE SURE THE NEW DETAILS BELOW MATCH THE ID DOCUMENTS."? > After fullfilling the assurance, system can display all data on the > single page, w/o possibility to edit. Than assurer can cancel or confirm. What would that help? The assurer already saw the details of the user and the only thing he is supposed to do is check+click. Why doing this twice? > Additionally time for this operation can be limited for for example > 60 sec. and applicant's record can be locked for this time. I see you point but I'd say there is no real advantage in locking user records. It would involve a lot of programming and lock checking but in the end the it doesn't change anything: The assurer still has to make sure the data on the screen is correct ... > Give us some time. > We will try to destroy testing system ;) > We will check it with diffrent browsers, also with windoza. Good luck. You have as much time as you like ;) Thanks for you help. |
|
|
> What about "Race condition discovered, user altered details during > assurance procedure. PLEASE MAKE SURE THE NEW DETAILS BELOW MATCH THE ID > DOCUMENTS."? > Looks OK > What would that help? The assurer already saw the details of the user and > the only thing he is supposed to do is check+click. Why doing this twice? > 1. When data is not able to edition, there is not possibility to change it unintentionally (for example you have additional line in your edition window) 2. You can read all data carfully and verify last time. NASK, who is holder of .pl domain doing like this (but, in fact you have to pot a lot of data before), I like this. Than I know, I sent my data correctly. > > Additionally time for this operation can be limited for for example > > 60 sec. and applicant's record can be locked for this time. > > I see you point but I'd say there is no real advantage in locking user > records. It would involve a lot of programming and lock checking but in > the end the it doesn't change anything: The assurer still has to make sure > the data on the screen is correct ... > It's true, but on the other hand still there is a moment (miliseconds) when collision is possible. > Good luck. You have as much time as you like ;) We agreed for Thursday and Friday |
|
|
>> What about "Race condition discovered, user altered details during >> assurance procedure. PLEASE MAKE SURE THE NEW DETAILS BELOW MATCH THE ID >> DOCUMENTS."? > > Looks OK OK, so no need for changes. This is the current message as implemented >6 month ago. ;) > 1. When data is not able to edition, there is not possibility to change > it unintentionally (for example you have additional line in your edition > window) > 2. You can read all data carfully and verify last time. > NASK, who is holder of .pl domain doing like this (but, in fact you have > to pot a lot of data before), I like this. Than I know, I sent my data > correctly. Is it possible that you're talking about the form where the user can change his data? There it would make sence to double check if the intended changes are correct (Please file another bug report/feature request if you like to have this). But not for the assurance form where the assurer is checking the name and date of birth of the user. > It's true, but on the other hand still there is a moment (miliseconds) > when collision is possible. This is an already known bug (see related bugs to this report). |
|
|
> OK, so no need for changes. This is the current message as implemented >6 > month ago. ;) I am sure, I haven't see this message. > Is it possible that you're talking about the form where the user can > change his data? There it would make sence to double check if the intended > changes are correct (Please file another bug report/feature request if you > like to have this). But not for the assurance form where the assurer is > checking the name and date of birth of the user. > I think, there is good idea to discuss it. But both (applicant data and assurance). However I am not sure if other people will like it. But automatic filing of the form is very danger. account administration category is OK? > This is an already known bug (see related bugs to this report). I know. (But summary for this bug is not OK missleading) This probably happend to us. I can see the following possibilities: - try to lock (as explained above) - use stored procedures (MySQL 5.0.18 ...) - it's working fine and very fast, but be carfull, I found very serious bug there - sometime data is not commited. - use InnoDB and transactions - but I don't like this sollution (I understand that, system is based on MySQL, as is explained in Mission Statement) |
|
|
On the test system it's working OK. I have got very nice message. We find some other errors with collaboration with browsers, but we will report it as another issue (related) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-04-04 19:47 | falkinhan | New Issue | |
| 2006-04-04 20:13 |
|
Relationship added | related to 0000192 |
| 2006-04-04 20:21 |
|
Note Added: 0000144 | |
| 2006-04-04 20:22 |
|
Relationship added | related to 0000193 |
| 2006-04-04 20:55 | falkinhan | Note Added: 0000145 | |
| 2006-04-04 22:35 |
|
Note Added: 0000147 | |
| 2006-04-04 23:18 | falkinhan | Note Added: 0000148 | |
| 2006-04-04 23:46 |
|
Note Added: 0000149 | |
| 2006-04-05 00:11 | falkinhan | Note Added: 0000150 | |
| 2006-04-05 00:40 |
|
Note Added: 0000151 | |
| 2006-04-05 01:47 | falkinhan | Note Added: 0000152 | |
| 2006-04-07 22:59 | falkinhan | Note Added: 0000154 | |
| 2006-04-21 18:07 |
|
Status | new => closed |
| 2006-04-21 18:07 |
|
Resolution | open => no change required |
| 2013-01-14 03:12 | Werner Dworak | Fixed in Version | => 2006 |
