View Issue Details

IDProjectCategoryView StatusLast Update
0000266Main CAcert Websiteaccount administrationpublic2013-01-14 09:48
Reporterwonderer Assigned To 
Status closedResolutionfixed 
Fixed in Version2006 
Summary0000266: My Alerts reset
Descriptionif 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 .
TagsNo tags attached.
Reviewed by
Test Instructions



2006-08-11 08:06

administrator   ~0000359

 includes/account.php : line 1857-1860 : Please replace _REQUEST with _POST , _REQUEST breaks the displaying


2006-08-13 05:58

developer   ~0000367

changed pages/account/36.php from $_POST to $_REQUEST


2006-08-13 06:18

administrator   ~0000368

Yes, it works for me now


2006-08-13 06:28

manager   ~0000370

Can anyone explain why the _REQUEST variable wouldn't work in this case?


2006-08-13 06:51

administrator   ~0000371

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.


2006-08-13 09:14

manager   ~0000372

I second this idea.


2006-08-13 10:45

developer   ~0000374

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.


2006-08-13 21:38

administrator   ~0000382

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


2006-08-14 02:40

developer   ~0000394

I haven't misunderstood anything, there is no need to pull the same information out of MySQL that we are putting into it.


2006-08-14 02:43

developer   ~0000395

moved lines 1854 to 1861 to line 1832

Issue History

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 bluec Note Added: 0000370
2006-08-13 06:51 Sourcerer Note Added: 0000371
2006-08-13 09:14 bluec Note Added: 0000372
2006-08-13 09:14 bluec Status closed => needs work
2006-08-13 09:14 bluec 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