View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000006 | Main CAcert Website | web of trust | public | 2005-08-24 16:53 | 2013-01-13 13:29 |
| Reporter | barabonkov | Assigned To | duane | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | won't fix | ||
| Fixed in Version | 2005 | ||||
| Summary | 0000006: Unintentional assurance of another person | ||||
| Description | While I was assuring two of my colleagues I opened up once a window for assuring the first person, printed out the pdf WoT form, and while waiting for him to fill it up and check it, I opened in new window second assuring form for the second person. I printed second form, which was handed out to the second person. Then the first one finished his paper work with the WoT form I returned to the first browser window and submitted the form, with intension of assuring him (as it was printed in the form). But reviewing the results of submission, I noticed that instead of him, I was assured the second person, whose form was printed last. I guess some of the form data is stored in the session and when there is more than one open form only the last open data is preserved. I think that problem should be addressed, at least with statement and assurers must be aware of this issue. | ||||
| Tags | No tags attached. | ||||
| Reviewed by | |||||
| Test Instructions | |||||
| related to | 0000063 | closed | I issued ZERO assurance points by mistake |
|
|
cacert support can now revoke assurance after verifying the assurer request |
|
|
As of Dec 2, 2005, Guillaume told me that we still have the bug, but maybe it would be difficult to fix. please investigate. |
|
|
The system is designed to process one form at a time, and we also store user information in sessions to that assurers won't get a surprise if data changes before the form is submitted. This is supposed to prevent a race condition with users altering their information after the assurer opens their information initially. |
|
|
I got a similar problem when I wanted to send mails to the assurers of a user. A user reported in august a really weird server certificate. in the CAcert admin interface, I selected a user, I clicked on each assurer links (in tabbed firefox pages) and put a message in each page, then click on "submit" in each tabbed page. I realized I've send all the messages to the last assurer I've opened a link, not to each assurer. Because in this case the datas are stored in the session... also - we can't do much with hidden fields in the form/data in the session - it's not so good to use sensitive data in the URL/hidden field |
|
|
We must add those variables as hidden fields in the HTML form, and verify, at submit, whether the fields match the values in the session, to make sure that no wrong assurance can be done. |
|
|
I don´t accept a WONTFIX. At least a verification at submit is necessary. We haven´t documented that this interface is for a single assurance at a time, so we have to support it, or give specific warnings/errors at the right time, instead of doing wrong things. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-08-24 16:53 | barabonkov | New Issue | |
| 2005-09-05 05:55 | duane | Status | new => @30@ |
| 2005-11-29 04:40 | homer | Status | @30@ => closed |
| 2005-11-29 04:40 | homer | Resolution | open => fixed |
| 2005-11-29 04:40 | homer | Fixed in Version | => production |
| 2005-11-29 04:42 | homer | Status | closed => solved? |
| 2005-11-29 04:42 | homer | Assigned To | => homer |
| 2005-11-29 04:42 | homer | Note Added: 0000045 | |
| 2005-12-02 11:49 | evaldo | Relationship added | related to 0000063 |
| 2005-12-02 23:56 | evaldo | Note Added: 0000055 | |
| 2005-12-02 23:56 | evaldo | Assigned To | homer => |
| 2005-12-02 23:56 | evaldo | Status | solved? => @30@ |
| 2005-12-03 00:08 | homer | Status | @30@ => new |
| 2005-12-03 00:43 | duane | Status | new => solved? |
| 2005-12-03 00:43 | duane | Resolution | fixed => won't fix |
| 2005-12-03 00:43 | duane | Assigned To | => duane |
| 2005-12-03 00:43 | duane | Note Added: 0000056 | |
| 2005-12-03 00:43 | duane | Status | solved? => closed |
| 2005-12-03 00:48 | homer | Note Added: 0000057 | |
| 2005-12-03 00:51 | Sourcerer | Note Added: 0000058 | |
| 2005-12-03 00:52 | Sourcerer | Status | closed => needs feedback |
| 2005-12-03 00:52 | Sourcerer | Resolution | won't fix => reopened |
| 2005-12-03 00:52 | Sourcerer | Note Added: 0000059 | |
| 2005-12-03 00:53 | duane | Status | needs feedback => closed |
| 2005-12-03 00:53 | duane | Resolution | reopened => won't fix |
| 2013-01-13 13:29 | Werner Dworak | Fixed in Version | => 2005 |
