Today

• 4 hours ago

  issue 385 (enhance TSoapServer::run() exception handling) commented on by ra...@bhatia.at   -   so, there will be no change then and one should use the code parameter?

  so, there will be no change then and one should use the code parameter?
• 13 hours ago

  issue 389 (TOutputCache hinders progressive rendering) commented on by google...@pcforum.hu   -   Small correction to the original patch. The latter referenced the wrong textwriter class (the one from my experimental codebase) and also didn't work correctly under certain circumstances (depending on how the original textwriter flushed the output).

  Small correction to the original patch. The latter referenced the wrong textwriter class (the one from my experimental codebase) and also didn't work correctly under certain circumstances (depending on how the original textwriter flushed the output).
• 14 hours ago

  issue 389 (TOutputCache hinders progressive rendering) reported by google...@pcforum.hu   -   Current implementation of TOuputCache hinders progressive rendering, because it captures and buffers the output of the controls encapsulated inside it on its own. This means that emission of output generated inside the TOutputCache control will be delayed until after rendering all the subcontrols has been finished, and will be push in one huge block to the client - therefore defeating the purpose of progressive rendering. Following patch works around the problem by introducing a special TTextWriter-descendant, which can write to multiple writers parallel and uses this feature to both buffer & send the generated content asap to the standard output at the same time.

  Current implementation of TOuputCache hinders progressive rendering, because it captures and buffers the output of the controls encapsulated inside it on its own. This means that emission of output generated inside the TOutputCache control will be delayed until after rendering all the subcontrols has been finished, and will be push in one huge block to the client - therefore defeating the purpose of progressive rendering. Following patch works around the problem by introducing a special TTextWriter-descendant, which can write to multiple writers parallel and uses this feature to both buffer & send the generated content asap to the standard output at the same time.
• 18 hours ago

  r3110 (updated quick start page "New features") committed by ctrlal...@gmail.com   -   updated quick start page "New features"

  updated quick start page "New features"
• 19 hours ago

  r3109 (small update to build scripts) committed by ctrlal...@gmail.com   -   small update to build scripts

  small update to build scripts
• 19 hours ago

  issue 385 (enhance TSoapServer::run() exception handling) Status changed by ctrlal...@gmail.com   -  

  Status: Done

  Status: Done
• 19 hours ago

  issue 386 (TClientScriptManager::registerScriptFile too strict) Status changed by ctrlal...@gmail.com   -   patched in r3108, thank you

  Status: Fixed

  patched in r3108, thank you

  Status: Fixed
• 19 hours ago

  r3108 (patch for #386) committed by ctrlal...@gmail.com   -   patch for #386

  patch for #386
• 19 hours ago

  issue 388 (Output caching will raise error in Performance mode ) Status changed by ctrlal...@gmail.com   -   Nice catch! patched in r3107 using proposed solution #1; i did not apply type hinting for the 3rd parameter since it's not commonly used anywhere else in prado.

  Status: Fixed

  Nice catch! patched in r3107 using proposed solution #1; i did not apply type hinting for the 3rd parameter since it's not commonly used anywhere else in prado.

  Status: Fixed
• 19 hours ago

  r3107 (patch for #388) committed by ctrlal...@gmail.com   -   patch for #388

  patch for #388
• 20 hours ago

  issue 387 (jsmin.php not found when using pradolite.php (and performanc...) Status changed by ctrlal...@gmail.com   -   patched in r3106

  Status: Fixed

  patched in r3106

  Status: Fixed
• 20 hours ago

  r3106 (patch for #387) committed by ctrlal...@gmail.com   -   patch for #387

  patch for #387

Yesterday

• 29 hours ago

  issue 388 (Output caching will raise error in Performance mode ) reported by google...@pcforum.hu   -   TOutputCache will fail and raise an exception (in performance mode) when 1. trying to server up already cached content and 2. if there are any controls inside it that are registered as requiring post data. This happens because TPage::registerRequiresPostData() registers post data handler actions in the wrong format. It calls $item->registerAction('Page','registerRequiresPostData',$id); for each item in the cache stack, but this format is wrong, because the 3rd parameter is supposed to be an array. This because when "replaying" said actions (in case of a successful cache hit) OutputCache::performActions() executes the following code: if($action[0]==='Page') call_user_func_array(array($page,$action[1]),$action[2]); which is clearly using the previously stored 3rd parameter of call_user_func_array() without an "array()" surrogate. So either the above line should be changed to call_user_func_array(array($page,$action[1]),array($action[2])); (which however is not recommened, because it will limit any future usage of said functionality to just one single parameter for each Page method action/call) or TPage::registerRequiresPostData() should be changed to store the method parameter(s) already in an array: $item->registerAction('Page','registerRequiresPostData',array($id)); Declaration of TOutputCache::registerAction() could also be changed so the 3rd parameter would be to be a type-checked array, ie. from: public function registerAction($context,$funcName,$funcParams) to public function registerAction($context,$funcName,Array $funcParams) to enforce that method parameters are always passed in array()s to it. Third option would be to convert any non-array $funcParams to an array in TOutputCache::registerAction() before storing them. That would be adding a if (!is_array($funcParams)) $funcParams = array($funcParams); to the first lines of said method.

  TOutputCache will fail and raise an exception (in performance mode) when 1. trying to server up already cached content and 2. if there are any controls inside it that are registered as requiring post data. This happens because TPage::registerRequiresPostData() registers post data handler actions in the wrong format. It calls $item->registerAction('Page','registerRequiresPostData',$id); for each item in the cache stack, but this format is wrong, because the 3rd parameter is supposed to be an array. This because when "replaying" said actions (in case of a successful cache hit) OutputCache::performActions() executes the following code: if($action[0]==='Page') call_user_func_array(array($page,$action[1]),$action[2]); which is clearly using the previously stored 3rd parameter of call_user_func_array() without an "array()" surrogate. So either the above line should be changed to call_user_func_array(array($page,$action[1]),array($action[2])); (which however is not recommened, because it will limit any future usage of said functionality to just one single parameter for each Page method action/call) or TPage::registerRequiresPostData() should be changed to store the method parameter(s) already in an array: $item->registerAction('Page','registerRequiresPostData',array($id)); Declaration of TOutputCache::registerAction() could also be changed so the 3rd parameter would be to be a type-checked array, ie. from: public function registerAction($context,$funcName,$funcParams) to public function registerAction($context,$funcName,Array $funcParams) to enforce that method parameters are always passed in array()s to it. Third option would be to convert any non-array $funcParams to an array in TOutputCache::registerAction() before storing them. That would be adding a if (!is_array($funcParams)) $funcParams = array($funcParams); to the first lines of said method.
• 29 hours ago

  issue 387 (jsmin.php not found when using pradolite.php (and performanc...) reported by google...@pcforum.hu   -   If 1. a Prado application is run using performance or normal mode and 2. its index.php is using the precomposited pradolite.php (instead of the regular prado.php) and 3. there are one or more Prado scripts referenced by the page or the controls on them, 4. there were no "using('System.Web.JavaScripts.*')" calls anywhere in the application code then page generation will fail in the TJavaScript::JSMin() method. This happens because said method tries to include the "jsmin.php" library, but does so using a relative reference, specifying no path name. While this does resolve correctly when prado.php is used (as in this case there's a distinct TJavaScript.php included and invoked, which resides in the same directory as said jsmin.php file), it will fail when using pradolite.php, which incorporates also the TJavaScript.php code, but resides in the framework root directory, and therefore will be unable to include the jsmin.php file without specifying its container directory. Unless of course when the container directory has been added to the search path using the above "using()" call.

  If 1. a Prado application is run using performance or normal mode and 2. its index.php is using the precomposited pradolite.php (instead of the regular prado.php) and 3. there are one or more Prado scripts referenced by the page or the controls on them, 4. there were no "using('System.Web.JavaScripts.*')" calls anywhere in the application code then page generation will fail in the TJavaScript::JSMin() method. This happens because said method tries to include the "jsmin.php" library, but does so using a relative reference, specifying no path name. While this does resolve correctly when prado.php is used (as in this case there's a distinct TJavaScript.php included and invoked, which resides in the same directory as said jsmin.php file), it will fail when using pradolite.php, which incorporates also the TJavaScript.php code, but resides in the framework root directory, and therefore will be unable to include the jsmin.php file without specifying its container directory. Unless of course when the container directory has been added to the search path using the above "using()" call.
• 29 hours ago

  issue 386 (TClientScriptManager::registerScriptFile too strict) reported by google...@pcforum.hu   -   The current TClientScriptManager::registerScriptFile() method is too strict, and doesn't allow registration of script files when rendering has already begun (eg. registration from ::render() methods). However, since <script> inclusions are also emitted at the end of the rendering phase, registration in this phase should be allowed too. To correct the issue the $this->checkIfNotInRender(); call in the TClientScriptManager::registerScriptFile() method should be removed.

  The current TClientScriptManager::registerScriptFile() method is too strict, and doesn't allow registration of script files when rendering has already begun (eg. registration from ::render() methods). However, since <script> inclusions are also emitted at the end of the rendering phase, registration in this phase should be allowed too. To correct the issue the $this->checkIfNotInRender(); call in the TClientScriptManager::registerScriptFile() method should be removed.

Last 7 days

• Feb 11, 2012

  r3105 (cleaning away unused converters from phpDocumentor) committed by ctrlal...@gmail.com   -   cleaning away unused converters from phpDocumentor

  cleaning away unused converters from phpDocumentor
• Feb 11, 2012

  issue 382 (TJavaScript::quoteString() vulnerable to Unicode strings & T...) commented on by ctrlal...@gmail.com   -   Good point on 1, i just missed it. About point 2, i just removed the "encode" word from the error message, since the stack strace already tells the developer the exact place where the exception gets triggered: #0 prado/framework/Web/Javascripts/TJavaScript.php(216): TJavaScript::checkJsonError() #1 prado/framework/Web/Javascripts/TJavaScript.php(86): TJavaScript::jsonEncode('??)???9?4?O ?', 13) #2 testcase/protected/Pages/Home.php(10): TJavaScript::quoteString('??)???9?4?O ?')

  Good point on 1, i just missed it. About point 2, i just removed the "encode" word from the error message, since the stack strace already tells the developer the exact place where the exception gets triggered: #0 prado/framework/Web/Javascripts/TJavaScript.php(216): TJavaScript::checkJsonError() #1 prado/framework/Web/Javascripts/TJavaScript.php(86): TJavaScript::jsonEncode('??)???9?4?O ?', 13) #2 testcase/protected/Pages/Home.php(10): TJavaScript::quoteString('??)???9?4?O ?')
• Feb 11, 2012

  r3104 (additional patch for #382) committed by ctrlal...@gmail.com   -   additional patch for #382

  additional patch for #382
• Feb 10, 2012

  issue 382 (TJavaScript::quoteString() vulnerable to Unicode strings & T...) commented on by google...@pcforum.hu   -   Patch needs corrections in TJavaScript::checkJsonError(): 1. "switch (json_last_error())" should be "switch ($err = json_last_error())" (otherwise there will be no $err for inclusion in the exception text) 2. also the text in the Exception next to the switch statement should be changed from "JSON encode error" to "JSON encode/decode error" as it is called both after encode and decode, and telling the developer that there was a "JSON encode error" whereas the error might have occoured (and is most likely to occour anyway) during a JSON-decode might be misleading, and make the developer to look for problems at the wrong places. even better solution would be to pass a string describing whether it was an encode/decode operation to the check function, and include that one in the exception text as well, so it would tell exactly whether the error was a decoding or encoding error.

  Patch needs corrections in TJavaScript::checkJsonError(): 1. "switch (json_last_error())" should be "switch ($err = json_last_error())" (otherwise there will be no $err for inclusion in the exception text) 2. also the text in the Exception next to the switch statement should be changed from "JSON encode error" to "JSON encode/decode error" as it is called both after encode and decode, and telling the developer that there was a "JSON encode error" whereas the error might have occoured (and is most likely to occour anyway) during a JSON-decode might be misleading, and make the developer to look for problems at the wrong places. even better solution would be to pass a string describing whether it was an encode/decode operation to the check function, and include that one in the exception text as well, so it would tell exactly whether the error was a decoding or encoding error.
• Feb 09, 2012

  issue 382 (TJavaScript::quoteString() vulnerable to Unicode strings & T...) Status changed by ctrlal...@gmail.com   -   Your patch has been committed in r3103. Some parts have been changed: - re-added mising JSMin() method; - unified error control code for jsonEncode and jsonDecode, and added conditional checks for the use of json_last_error() that requires php5.3; - changed quoteString() behaviour to actually add quotes around the string, avoiding the need to strip them off after json_encode()

  Status: Fixed

  Your patch has been committed in r3103. Some parts have been changed: - re-added mising JSMin() method; - unified error control code for jsonEncode and jsonDecode, and added conditional checks for the use of json_last_error() that requires php5.3; - changed quoteString() behaviour to actually add quotes around the string, avoiding the need to strip them off after json_encode()

  Status: Fixed
• Feb 09, 2012

  r3103 (patch for #382) committed by ctrlal...@gmail.com   -   patch for #382

  patch for #382
• Feb 09, 2012

  issue 382 (TJavaScript::quoteString() vulnerable to Unicode strings & T...) commented on by ctrlal...@gmail.com   -   I managed to reproduce the problem using your example code under osx.

  I managed to reproduce the problem using your example code under osx.
• Feb 07, 2012

  issue 385 (enhance TSoapServer::run() exception handling) commented on by ra...@bhatia.at   -   according to a comment in http://php.net/manual/en/soapfault.soapfault.php#84426 the code must conform to the specification. I quickly scanned http://www.w3.org/TR/soap12-part1/#faultcodes and thought that the most appropriate location for the actual error would be the detail part of a soap fault message, e.g. "<m:MaxTime>P5M</m:MaxTime>" On the other side, PHP automatically uses "Server" or "Client" as the code, depending on where the error occured: Server: e.g. SoapFault sent from the Server Client: e.g. parse error on the client side because of an invalid XML document. however, i do not find myself qualified enough to judge the "correct" way :) thanks, raoul

  according to a comment in http://php.net/manual/en/soapfault.soapfault.php#84426 the code must conform to the specification. I quickly scanned http://www.w3.org/TR/soap12-part1/#faultcodes and thought that the most appropriate location for the actual error would be the detail part of a soap fault message, e.g. "<m:MaxTime>P5M</m:MaxTime>" On the other side, PHP automatically uses "Server" or "Client" as the code, depending on where the error occured: Server: e.g. SoapFault sent from the Server Client: e.g. parse error on the client side because of an invalid XML document. however, i do not find myself qualified enough to judge the "correct" way :) thanks, raoul

Last 30 days

• Feb 05, 2012

  issue 382 (TJavaScript::quoteString() vulnerable to Unicode strings & T...) commented on by ctrlal...@gmail.com   -   Side note: TPage actually tries to decode the postData in processCallbackRequest: // Decode Callback postData from UTF-8 to current Charset if (($g=$this->getApplication()->getGlobalization(false))!==null && strtoupper($enc=$g->getCharset())!='UTF-8') foreach ($this->_postData as $k=>$v) $this->_postData[$k]=iconv('UTF-8',$enc.'//IGNORE',$v);

  Side note: TPage actually tries to decode the postData in processCallbackRequest: // Decode Callback postData from UTF-8 to current Charset if (($g=$this->getApplication()->getGlobalization(false))!==null && strtoupper($enc=$g->getCharset())!='UTF-8') foreach ($this->_postData as $k=>$v) $this->_postData[$k]=iconv('UTF-8',$enc.'//IGNORE',$v);
• Feb 05, 2012

  r3102 (Make validators' FocusOnError play nice with TCheckBoxList a...) committed by ctrlal...@gmail.com   -   Make validators' FocusOnError play nice with TCheckBoxList and TRadioButtonList

  Make validators' FocusOnError play nice with TCheckBoxList and TRadioButtonList
• Feb 05, 2012

  issue 385 (enhance TSoapServer::run() exception handling) commented on by ctrlal...@gmail.com   -   Currently the function signature is: TSoapServer::fault($title, $details='', $code='SERVER', $actor='', $name=''); The error code should be passed as the third parameter; thse are in turn passed to php's SoapServer class: http://it.php.net/manual/en/soapserver.fault.php (note that parameters are in different order). Is this eough or am i missing something?

  Currently the function signature is: TSoapServer::fault($title, $details='', $code='SERVER', $actor='', $name=''); The error code should be passed as the third parameter; thse are in turn passed to php's SoapServer class: http://it.php.net/manual/en/soapserver.fault.php (note that parameters are in different order). Is this eough or am i missing something?
• Feb 03, 2012

  issue 385 (enhance TSoapServer::run() exception handling) reported by ra...@bhatia.at   -   hi! could you please enhance the exception handling of TSoapServer::run() so that one can pass more information regarding the exception to the client (most importantly the exception's code). my current working hack passes the code via the $details parameter: $this->fault($e->getMessage(), $e->getCode()); however, i'm not familiar enough to judge what the SOAP way should be. thanks, raoul

  hi! could you please enhance the exception handling of TSoapServer::run() so that one can pass more information regarding the exception to the client (most importantly the exception's code). my current working hack passes the code via the $details parameter: $this->fault($e->getMessage(), $e->getCode()); however, i'm not familiar enough to judge what the SOAP way should be. thanks, raoul
• Feb 02, 2012

  r3101 (Added some dirty js code to get dropcontainer-relative offse...) committed by ctrlal...@gmail.com   -   Added some dirty js code to get dropcontainer-relative offset for onDrop events of draggable controls

  Added some dirty js code to get dropcontainer-relative offset for onDrop events of draggable controls
• Feb 01, 2012

  r3100 (fix: css registration upon callback was missing some files f...) committed by ctrlal...@gmail.com   -   fix: css registration upon callback was missing some files from getting rendered

  fix: css registration upon callback was missing some files from getting rendered
• Jan 31, 2012

  issue 384 (PHP Warning Mesage when using TMemCache & I18N) Status changed by ctrlal...@gmail.com   -   No problem

  Status: Invalid

  No problem

  Status: Invalid
• Jan 31, 2012

  issue 384 (PHP Warning Mesage when using TMemCache & I18N) commented on by tleidin...@gmail.com   -   You can close this issue - it was a problem on our side. We didn't use the cache properly. Sorry

  You can close this issue - it was a problem on our side. We didn't use the cache properly. Sorry
• Jan 31, 2012

  issue 384 (PHP Warning Mesage when using TMemCache & I18N) Status changed by ctrlal...@gmail.com   -   Unfortunately not even the full log gives us enough information on what's causing the problem. I've set up a small testcase that uses memcache+i18n and it seems to work here, can you test it and modify it so that it actually causes the error?

  Status: Accepted

  Unfortunately not even the full log gives us enough information on what's causing the problem. I've set up a small testcase that uses memcache+i18n and it seems to work here, can you test it and modify it so that it actually causes the error?

  Status: Accepted
• Jan 30, 2012

  issue 384 (PHP Warning Mesage when using TMemCache & I18N) commented on by tleidin...@gmail.com   -   exception 'TPhpErrorE xception' with message '[Warning] call_user_func_array() expects parameter 2 to be array, string given (@line 6887 in file /var/www/prado/framework_statista/pra dolite.php).' in /var/www/prado/framework_statista/pradolite.php:56\nStack trace :\n#0 [internal function]: PradoBase::phpErrorHandler(2, 'call_user_func_...', ' /var/www/prado/...', 6887, Array)\n#1 /var/www/prado/framework_statista/pradolit e.php(6887): call_user_func_array(Array, 'ctl0$content$ct...')\n#2 /var/www/prad o/framework_statista/pradolite.php(6874): TOutputCache->performActions()\n#3 /va r/www/prado/framework_statista/pradolite.php(4217): TOutputCache->loadRecursive( )\n#4 /var/www/prado/framework_statista/pradolite.php(4217): TControl->loadRecur sive()\n#5 /var/www/prado/framework_statista/pradolite.php(4217): TControl->load Recursive()\n#6 /var/www/prado/framework_statista/pradolite.php(4217): TControl- >loadRecursive()\n#7 /var/www/prado/framework_statista/pradolite.php(4217): TCon trol->loadRecursive()\n#8 /var/www/prado/framework_statista/pradolite.php(4217): TControl->loadRecursive()\n#9 /var/www/prado/framework_statista/pradolite.php(6 223): TControl->loadRecursive()\n#10 /var/www/prado/framework_statista/pradolite .php(6215): TPage->processNormalRequest(Object(THtmlWriter))\n#11 /var/www/prado /framework_statista/pradolite.php(8340): TPage->run(Object(THtmlWriter))\n#12 /v ar/www/prado/framework_statista/pradolite.php(8306): TPageService->runPage(Objec t(home), Array)\n#13 /var/www/prado/framework_statista/pradolite.php(9297): TPag eService->run()\n#14 /var/www/prado/framework_statista/pradolite.php(8899): TApp lication->runService()\n#15 /var/www/prado/statista_test4/index.php(22): TApplic ation->run()\n#16 {main}

  exception 'TPhpErrorE xception' with message '[Warning] call_user_func_array() expects parameter 2 to be array, string given (@line 6887 in file /var/www/prado/framework_statista/pra dolite.php).' in /var/www/prado/framework_statista/pradolite.php:56\nStack trace :\n#0 [internal function]: PradoBase::phpErrorHandler(2, 'call_user_func_...', ' /var/www/prado/...', 6887, Array)\n#1 /var/www/prado/framework_statista/pradolit e.php(6887): call_user_func_array(Array, 'ctl0$content$ct...')\n#2 /var/www/prad o/framework_statista/pradolite.php(6874): TOutputCache->performActions()\n#3 /va r/www/prado/framework_statista/pradolite.php(4217): TOutputCache->loadRecursive( )\n#4 /var/www/prado/framework_statista/pradolite.php(4217): TControl->loadRecur sive()\n#5 /var/www/prado/framework_statista/pradolite.php(4217): TControl->load Recursive()\n#6 /var/www/prado/framework_statista/pradolite.php(4217): TControl- >loadRecursive()\n#7 /var/www/prado/framework_statista/pradolite.php(4217): TCon trol->loadRecursive()\n#8 /var/www/prado/framework_statista/pradolite.php(4217): TControl->loadRecursive()\n#9 /var/www/prado/framework_statista/pradolite.php(6 223): TControl->loadRecursive()\n#10 /var/www/prado/framework_statista/pradolite .php(6215): TPage->processNormalRequest(Object(THtmlWriter))\n#11 /var/www/prado /framework_statista/pradolite.php(8340): TPage->run(Object(THtmlWriter))\n#12 /v ar/www/prado/framework_statista/pradolite.php(8306): TPageService->runPage(Objec t(home), Array)\n#13 /var/www/prado/framework_statista/pradolite.php(9297): TPag eService->run()\n#14 /var/www/prado/framework_statista/pradolite.php(8899): TApp lication->runService()\n#15 /var/www/prado/statista_test4/index.php(22): TApplic ation->run()\n#16 {main}
• Jan 30, 2012

  issue 384 (PHP Warning Mesage when using TMemCache & I18N) commented on by ctrlal...@gmail.com   -   Can you please post the full error and not only the last line of it?

  Can you please post the full error and not only the last line of it?
• Jan 30, 2012

  issue 384 (PHP Warning Mesage when using TMemCache & I18N) reported by tleidin...@gmail.com   -   I keep on getting this error: [Warning] call_user_func_array() expects parameter 2 to be array, string given (@line 190 in file ${PradoFramework}/Web/UI/WebControls/TOutputCache.php). when using I18N with caching. When I change the lines there like here, it works: if($action[0]==='Page.ClientScript') call_user_func_array(array($cs,$action[1]),$action[2]); else if($action[0]==='Page') call_user_func_array(array($page,$action[1]),array($action[2])); else call_user_func_array(array($this->getSubProperty($action[0]),$action[1]), array($action[2])); But is this correct to do so? What version of the product are you using? On what operating system? PHP 5.3.6 & Prado 3.1.10

  I keep on getting this error: [Warning] call_user_func_array() expects parameter 2 to be array, string given (@line 190 in file ${PradoFramework}/Web/UI/WebControls/TOutputCache.php). when using I18N with caching. When I change the lines there like here, it works: if($action[0]==='Page.ClientScript') call_user_func_array(array($cs,$action[1]),$action[2]); else if($action[0]==='Page') call_user_func_array(array($page,$action[1]),array($action[2])); else call_user_func_array(array($this->getSubProperty($action[0]),$action[1]), array($action[2])); But is this correct to do so? What version of the product are you using? On what operating system? PHP 5.3.6 & Prado 3.1.10
• Jan 29, 2012

  issue 382 (TJavaScript::quoteString() vulnerable to Unicode strings & T...) commented on by ctrlal...@gmail.com   -   Sorry, i answered without seeing your comment #2 and #3. Yes i'm using UTF8, and here's a screenshot of the result:

  Sorry, i answered without seeing your comment #2 and #3. Yes i'm using UTF8, and here's a screenshot of the result:
• Jan 29, 2012

  issue 382 (TJavaScript::quoteString() vulnerable to Unicode strings & T...) commented on by ctrlal...@gmail.com   -   I tested a bit the code involved and the first idea i had was to completely replace prado's TJavascript::encode() with json_encode. This creates some easy-to-resolve issues (avoid encoding "javascript:" strings, workaround INF(inite), fix controls like TDatePicker), but there's also a bigger issue that needs to be solved. Json_[en|de]code is only able to work on UTF8, while the actual TJavascript methods takes different approaches: - encode() and quoteString() seems to have been charset-agnostic at first, but then quoteUTF8() has been added, caisung them to become UTF8-only; - jsonEncode(), as you noticed, tries to convert from the Application->Globalization->Charset to UTF8 before encoding; - jsonDecode() doesn's validate its input, and will fail if it's not UTF8; - the same jsonEncode() and jsonDecode() behaviours appears in the TJSON php implementation. Assuming that TJavaScript::encode() was written first as a low-computational-cost alternative to a full php json implementation (php's json extension was not available at the time of prado 3.0.0), and that nowadays json_encode is surely quickier than any php-based alternative, the idea of just trashing TJavascript::encode() can be meaningful. This will make prado use UTF-8 only for javascript and ajax. I'd like to note that our globalization stuff is already UTF8-only. As an example, setting in application.xml <module id="globalization" class="TGlobalization" Culture="zh" Charset="GB-2312" /> will make TDatePicker month and week days appear as mojibake. So my idea would be to: 1. use json_encode() instead of encode(); 2. fix the involved code; 3. deprecate TJSON to avoid people from using it; 4a. explicitly state in the documentation that everything related to Javascript uses UTF8, or 4b. add proper _toUTF8 and _fromUTF8 routines to both php and javascript to be able to convert from Application->Globalization->Charset to UTF8 and viceversa. Sorry for derailing your ticket.

  I tested a bit the code involved and the first idea i had was to completely replace prado's TJavascript::encode() with json_encode. This creates some easy-to-resolve issues (avoid encoding "javascript:" strings, workaround INF(inite), fix controls like TDatePicker), but there's also a bigger issue that needs to be solved. Json_[en|de]code is only able to work on UTF8, while the actual TJavascript methods takes different approaches: - encode() and quoteString() seems to have been charset-agnostic at first, but then quoteUTF8() has been added, caisung them to become UTF8-only; - jsonEncode(), as you noticed, tries to convert from the Application->Globalization->Charset to UTF8 before encoding; - jsonDecode() doesn's validate its input, and will fail if it's not UTF8; - the same jsonEncode() and jsonDecode() behaviours appears in the TJSON php implementation. Assuming that TJavaScript::encode() was written first as a low-computational-cost alternative to a full php json implementation (php's json extension was not available at the time of prado 3.0.0), and that nowadays json_encode is surely quickier than any php-based alternative, the idea of just trashing TJavascript::encode() can be meaningful. This will make prado use UTF-8 only for javascript and ajax. I'd like to note that our globalization stuff is already UTF8-only. As an example, setting in application.xml <module id="globalization" class="TGlobalization" Culture="zh" Charset="GB-2312" /> will make TDatePicker month and week days appear as mojibake. So my idea would be to: 1. use json_encode() instead of encode(); 2. fix the involved code; 3. deprecate TJSON to avoid people from using it; 4a. explicitly state in the documentation that everything related to Javascript uses UTF8, or 4b. add proper _toUTF8 and _fromUTF8 routines to both php and javascript to be able to convert from Application->Globalization->Charset to UTF8 and viceversa. Sorry for derailing your ticket.
• Jan 29, 2012

  issue 382 (TJavaScript::quoteString() vulnerable to Unicode strings & T...) commented on by google...@pcforum.hu   -   Testcase attached. Reproduces using original trunk sources flawlessly. I'm using PHP 5.3.6/VC9, but that shouldn't matter.

  Testcase attached. Reproduces using original trunk sources flawlessly. I'm using PHP 5.3.6/VC9, but that shouldn't matter.
• Jan 29, 2012

  issue 382 (TJavaScript::quoteString() vulnerable to Unicode strings & T...) commented on by google...@pcforum.hu   -   Are you using utf-8 encoding and content-type header for your pages?

  Are you using utf-8 encoding and content-type header for your pages?
• Jan 29, 2012

  issue 382 (TJavaScript::quoteString() vulnerable to Unicode strings & T...) commented on by ctrlal...@gmail.com   -   Quick notice: hex2bin doesn't still exists in php 5.3, so i've not been able to test your example; i tried using unpack("H*", ..) and hexdec(decbin(..)), but they didn't work (an alert was correctly displayed).

  Quick notice: hex2bin doesn't still exists in php 5.3, so i've not been able to test your example; i tried using unpack("H*", ..) and hexdec(decbin(..)), but they didn't work (an alert was correctly displayed).
• Jan 29, 2012

  issue 383 (Some THttpRequest methods raise NOTICE level errors on missi...) Status changed by ctrlal...@gmail.com   -   Patched in r3099. From some quick tests the use of the simpler "@-way" seems to be a 1.75x slower the the isset/ternary operator alternative. No real deal, but i preferred the faster one. Some of the old methods (getQueryString and getHttpProtocolVersion) previously returned an empty string; all the methods have been paired up to return null instead.

  Status: Fixed

  Patched in r3099. From some quick tests the use of the simpler "@-way" seems to be a 1.75x slower the the isset/ternary operator alternative. No real deal, but i preferred the faster one. Some of the old methods (getQueryString and getHttpProtocolVersion) previously returned an empty string; all the methods have been paired up to return null instead.

  Status: Fixed
• Jan 29, 2012

  r3099 (fix #383) committed by ctrlal...@gmail.com   -   fix #383

  fix #383
• Jan 28, 2012

  issue 383 (Some THttpRequest methods raise NOTICE level errors on missi...) reported by google...@pcforum.hu   -   Some THttpRequest methods seem to make Prado scripts unneccessarily raise NOTICE level error messages (ie. [Notice] Undefined index: XYZ) when certain HTTP headers aren't supplied (for whatever reason) in the request initating the page download. For ex. THttpRequest::getUserHost() checks whether there's a REMOTE_HOST header supplied, and if it isn't, it gracefully returns an empty string instead. However, ::getUserHostAddress(), ::getUserAgent(), etc. all raise NOTICEs if their respective headers aren't present in the request. I see no logic behind this, as none of these are mandatory HTTP headers, and their presence is not critical for the Prado framework to function properly. Therefore I propose the modification of said methods so all of them will gracefully return empty strings - or whatever value appropriate - if their respective headers aren't present in the $_SERVER array. However, instead of the "return isset($_SERVER[$x]) ? $_SERVER[$x] : ''" form it would be simpler to use the error supression prefix @, like "return @$_SERVER[x]". The latter will return NULL if the header is not present (which in turn will convert to an empty string if interpreted as / juggled to such), and the supplied value if the header is present.

  Some THttpRequest methods seem to make Prado scripts unneccessarily raise NOTICE level error messages (ie. [Notice] Undefined index: XYZ) when certain HTTP headers aren't supplied (for whatever reason) in the request initating the page download. For ex. THttpRequest::getUserHost() checks whether there's a REMOTE_HOST header supplied, and if it isn't, it gracefully returns an empty string instead. However, ::getUserHostAddress(), ::getUserAgent(), etc. all raise NOTICEs if their respective headers aren't present in the request. I see no logic behind this, as none of these are mandatory HTTP headers, and their presence is not critical for the Prado framework to function properly. Therefore I propose the modification of said methods so all of them will gracefully return empty strings - or whatever value appropriate - if their respective headers aren't present in the $_SERVER array. However, instead of the "return isset($_SERVER[$x]) ? $_SERVER[$x] : ''" form it would be simpler to use the error supression prefix @, like "return @$_SERVER[x]". The latter will return NULL if the header is not present (which in turn will convert to an empty string if interpreted as / juggled to such), and the supplied value if the header is present.
• Jan 28, 2012

  issue 382 (TJavaScript::quoteString() vulnerable to Unicode strings & T...) reported by google...@pcforum.hu   -   What steps will reproduce the problem? 1. Create a new page 2. Add the line "$this->Page->ClientScript->registerEndScript('abcd', 'alert(\''.TJavaScript::quoteString(hex2bin('920629d49ad739c034124f208d')).'\');');" to the onPreRender method 3. Run/load the page What is the expected output? What do you see instead? You'd expect a JavaScript message box to show. However, nothing happens. If you open up your browsers console you see that there is a parse/script error in the page (IE&FF complain about an unterminated string contant, Chrome about an invalid token.) This happens because TJavaScript::quoteString() fails to properly encode some Unicode sequences. The example above contains a malformed sequence, but there might be other sequences which cause similar errors (as TJavaScript::quoteString encodes only some special characters, and does not use Unicode hex encoding at all). Also malformed Unicode sequences could be very well submitted by a web user to the Prado application, which then in turn could store that in a database or a file, and make itself vulnerable to XSS attacks when trying to use this malformed data in a quoted string, because of relying on TJavaScript::quoteString() to properly encode every possible sequence (which it actually does NOT). As a solution I've devised to use TJavaScript::jsonEncode() to encode the string, which will 1. check the passed string for sanity and 2. is probably the fastest way to transcode PHP strings to escaped JavaScript strings in a Unicode-aware way, thus preventing the above XSS attacks. However, upon trying to work around the original problem by calling TJavaScript::jsonEncode() I've realized that the latter calls json_encode() without checking afterwards whether there were any encoding errors. So if you pass a string with for ex. an invalid Unicode sequence (or an array or object containing one or more strings with invalid Unicode sequences) to it, even though it will refuse to encode the string - thus preventing the above or any other XSS attacks -, but will simply return 'null', without raising any error or exception. This, even though not a vulnerability per se, is not good, as obviously such encoding errors should be signaled to the application code - because if gone undetected, this malfunction might cause data-loss. So, I've added some error checks to TJavaScript::jsonEncode() which will now check whether the encoding was successful, and if not, will raise an appropriate exception for the application code to handle (or for the request to fail with an error). These two measures together should prevent any possible XSS vulnerabilites using malformed string in conjuction with TJavaScript::quoteString() and also ::jsonEncode() conversion errors - for whatever reason - going undetected. I've attached the patches TJavaScript.php for review. Btw. TJavaScript::jsonDecode() has no error checks implemented either, but I didn't bother putting some in there, which however should be trivial to add. I've also noticed that it does no Unicode->Application code page conversion - which would be logical to do, if jsonEncode() does the opposite of that automatically. What version of the product are you using? On what operating system? Prado/trunk

  What steps will reproduce the problem? 1. Create a new page 2. Add the line "$this->Page->ClientScript->registerEndScript('abcd', 'alert(\''.TJavaScript::quoteString(hex2bin('920629d49ad739c034124f208d')).'\');');" to the onPreRender method 3. Run/load the page What is the expected output? What do you see instead? You'd expect a JavaScript message box to show. However, nothing happens. If you open up your browsers console you see that there is a parse/script error in the page (IE&FF complain about an unterminated string contant, Chrome about an invalid token.) This happens because TJavaScript::quoteString() fails to properly encode some Unicode sequences. The example above contains a malformed sequence, but there might be other sequences which cause similar errors (as TJavaScript::quoteString encodes only some special characters, and does not use Unicode hex encoding at all). Also malformed Unicode sequences could be very well submitted by a web user to the Prado application, which then in turn could store that in a database or a file, and make itself vulnerable to XSS attacks when trying to use this malformed data in a quoted string, because of relying on TJavaScript::quoteString() to properly encode every possible sequence (which it actually does NOT). As a solution I've devised to use TJavaScript::jsonEncode() to encode the string, which will 1. check the passed string for sanity and 2. is probably the fastest way to transcode PHP strings to escaped JavaScript strings in a Unicode-aware way, thus preventing the above XSS attacks. However, upon trying to work around the original problem by calling TJavaScript::jsonEncode() I've realized that the latter calls json_encode() without checking afterwards whether there were any encoding errors. So if you pass a string with for ex. an invalid Unicode sequence (or an array or object containing one or more strings with invalid Unicode sequences) to it, even though it will refuse to encode the string - thus preventing the above or any other XSS attacks -, but will simply return 'null', without raising any error or exception. This, even though not a vulnerability per se, is not good, as obviously such encoding errors should be signaled to the application code - because if gone undetected, this malfunction might cause data-loss. So, I've added some error checks to TJavaScript::jsonEncode() which will now check whether the encoding was successful, and if not, will raise an appropriate exception for the application code to handle (or for the request to fail with an error). These two measures together should prevent any possible XSS vulnerabilites using malformed string in conjuction with TJavaScript::quoteString() and also ::jsonEncode() conversion errors - for whatever reason - going undetected. I've attached the patches TJavaScript.php for review. Btw. TJavaScript::jsonDecode() has no error checks implemented either, but I didn't bother putting some in there, which however should be trivial to add. I've also noticed that it does no Unicode->Application code page conversion - which would be logical to do, if jsonEncode() does the opposite of that automatically. What version of the product are you using? On what operating system? Prado/trunk
• Jan 28, 2012

  r3098 (some fixes related to build scripts, now the "dist" task com...) committed by ctrlal...@gmail.com   -   some fixes related to build scripts, now the "dist" task completes successfully

  some fixes related to build scripts, now the "dist" task completes successfully
• Jan 25, 2012

  issue 379 (JSON float encoding depends on current locale) commented on by ctrlal...@gmail.com   -   I've committed r3097 that makes TJsonService use TJavaScript::jsonEncode().

  I've committed r3097 that makes TJsonService use TJavaScript::jsonEncode().
• Jan 25, 2012

  r3097 (TJsonService: use TJavaScript::jsonEncode() instead of the o...) committed by ctrlal...@gmail.com   -   TJsonService: use TJavaScript::jsonEncode() instead of the old, slower TJSON class

  TJsonService: use TJavaScript::jsonEncode() instead of the old, slower TJSON class
• Jan 25, 2012

  issue 379 (JSON float encoding depends on current locale) commented on by google...@pcforum.hu   -   The TJsonService is still explicitly instantiating the TJSON class and using it's encode() method. I'm not sure whether this is neccessary or TJavaScript::jsonEncode() could do the same job there (which in turn would call json_encode() if available), but in its current implementation is surely effected by this bug.

  The TJsonService is still explicitly instantiating the TJSON class and using it's encode() method. I'm not sure whether this is neccessary or TJavaScript::jsonEncode() could do the same job there (which in turn would call json_encode() if available), but in its current implementation is surely effected by this bug.
• Jan 25, 2012

  r3096 (updated HISTORY) committed by ctrlal...@gmail.com   -   updated HISTORY

  updated HISTORY
• Jan 25, 2012

  issue 379 (JSON float encoding depends on current locale) Status changed by ctrlal...@gmail.com   -   Since i did not receive any feedback, i've committed the patch as r3095. As previously noticed, since prado 3.2 requires php 5.2, TJSON should not be needed anymore, but it's provided just for backwards compatibility.

  Status: Fixed

  Since i did not receive any feedback, i've committed the patch as r3095. As previously noticed, since prado 3.2 requires php 5.2, TJSON should not be needed anymore, but it's provided just for backwards compatibility.

  Status: Fixed