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|
|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.|
||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...
- 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.|
|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|