View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000266 | Main CAcert Website | account administration | public | 2006-07-20 22:43 | 2013-01-14 09:48 |
| Reporter | wonderer | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 2006 | ||||
| Summary | 0000266: My Alerts reset | ||||
| Description | if set something in the "my Alerts" Field this will be reset to "nothing" if "my Alerts" will be pressed again. If there is something set, there was no proof of it . | ||||
| Tags | No tags attached. | ||||
| Reviewed by | |||||
| Test Instructions | |||||
|
|
Fix: includes/account.php : line 1857-1860 : Please replace _REQUEST with _POST , _REQUEST breaks the displaying |
|
|
changed pages/account/36.php from $_POST to $_REQUEST |
|
|
Yes, it works for me now |
|
|
Can anyone explain why the _REQUEST variable wouldn't work in this case? |
|
|
Ok, I´ll give the long explanation: The _REQUEST , _POST and _GET are normal arrays in PHP, which are filled by the PHP engine before the PHP script is started. Those 3 arrays are independent, normal arrays. The reason why _REQUEST contains both the same values as _POST and _GET is that it is filled that way in the beginning. What CAcert is doing in the sourcecode there is "abusing" that array to store and handover the data from the internal CAcert engine (which requests the current values from the database, and stores it in the array) to the displaying part of the CAcert website (which diplays the values to the user then). PHP is very different from Perl in this regard. In the CGI module of Perl, the CGI module makes the HTTP parameters available through a blessed object, which only gives a read-only access to the parameters, so the application can´t abuse it to store values in it. (Although it also looks like a normal hash to the application). Now what caused the bug: The frontend code was changed to read the values from _POST, but the backend still put the values in _REQUEST. Since most people think that _REQUEST and _POST always contain the same values (when the form is sent with POST), it wasn´t obvious, why the values were not available. But they are independent normal arrays, which just happen to be filled by PHP in the beginning, but never touched or used by the PHP engine afterwards. Now that I thought it through again, I think we should reopen this bug, and remove the database lookup in the backend, and move it to the frontend, which should make transporting the values through _REQUEST or _POST unnecessary. We are relying on a non-guaranteed "feature" of PHP there, which might change in the future. |
|
|
I second this idea. |
|
|
The account.php script is making a change to the database, but instead of wasting a MySQL call we just pre-fill values, I see no point in doing an additional lookup in mysql for values that only have a minor effect on users. |
|
|
Duane, you have misunderstood this. Leave the MySQL change code (lines 1832-1852) in the includes file, but move the mysql read code (lines 1854-1861) to the account/36.php |
|
|
I haven't misunderstood anything, there is no need to pull the same information out of MySQL that we are putting into it. |
|
|
moved lines 1854 to 1861 to line 1832 |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-07-20 22:43 | wonderer | New Issue | |
| 2006-08-11 08:06 | Sourcerer | Note Added: 0000359 | |
| 2006-08-11 08:06 | Sourcerer | Status | new => needs work |
| 2006-08-11 08:06 | Sourcerer | Assigned To | => duane |
| 2006-08-13 05:58 | duane | Status | needs work => solved? |
| 2006-08-13 05:58 | duane | Fixed in Version | => production |
| 2006-08-13 05:58 | duane | Resolution | open => fixed |
| 2006-08-13 05:58 | duane | Note Added: 0000367 | |
| 2006-08-13 06:18 | Sourcerer | Status | solved? => closed |
| 2006-08-13 06:18 | Sourcerer | Note Added: 0000368 | |
| 2006-08-13 06:28 |
|
Note Added: 0000370 | |
| 2006-08-13 06:51 | Sourcerer | Note Added: 0000371 | |
| 2006-08-13 09:14 |
|
Note Added: 0000372 | |
| 2006-08-13 09:14 |
|
Status | closed => needs work |
| 2006-08-13 09:14 |
|
Resolution | fixed => reopened |
| 2006-08-13 10:45 | duane | Status | needs work => closed |
| 2006-08-13 10:45 | duane | Note Added: 0000374 | |
| 2006-08-13 10:45 | duane | Resolution | reopened => fixed |
| 2006-08-13 21:38 | Sourcerer | Note Added: 0000382 | |
| 2006-08-13 21:38 | Sourcerer | Status | closed => @30@ |
| 2006-08-14 02:40 | duane | Status | @30@ => solved? |
| 2006-08-14 02:40 | duane | Note Added: 0000394 | |
| 2006-08-14 02:43 | duane | Note Added: 0000395 | |
| 2007-10-24 06:20 | evaldo | Assigned To | duane => |
| 2007-10-24 06:20 | evaldo | Status | solved? => closed |
| 2013-01-14 09:48 | Werner Dworak | Fixed in Version | => 2006 |
