Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 3.2.16

Bug #12736 Form validation breaks when using regex rule with unicode escape codes
Submitted: 2007-12-20 18:17 UTC
From: mpgjunky Assigned: avb
Status: Closed Package: HTML_QuickForm (version 3.2.10)
PHP Version: 5.1.6 OS: Fedora 6
Roadmaps: 3.2.11    
Subscription  


 [2007-12-20 18:17 UTC] mpgjunky (Michael Mussulis)
Description: ------------ When a regex rule is defined that uses unicode escape code, the form validation fails on the server side. Javascript validation will pass. This is because of the difference between the regex engines of JS and PHP respectively and unicode support. In JS you have to use \udddd whereas in PHP you would use \x{xxxx}. Since both the client side and server side validation are performed for security reasons, one validation will pass whilst the other will not. Test script: --------------- $form = new HTML_QuickForm("offers"); $form->addElement("textarea", "description", "Description:"); $form->addRule("description", "Invalid characters", "regex", "/^[\x21-\x7e\s\u00a3]*$/", "client"); if($form->validate()) { die("ok"); } else $form->display(); Expected result: ---------------- The form should pass both client & server side validations. Perhaps the server side validation should automatically use the correct form for unicode.

Comments

 [2009-04-05 01:15 UTC] avb (Alexey Borzov)
-Status: Open +Status: Analyzed -Assigned To: +Assigned To: avb
Technically it is more a feature request than a bug, we never advertised conversion of regexp flavors between PHP and Javascript. Anyway, PHP flavor of regular expressions should be the base here, since client-side validation is optional. Thus it should read $form->addRule("description", "Invalid characters", "regex", "/^[\x21-\x7e\s\x{00a3}]*$/u", "client"); while 'u' modifier should be stripped for Javascript and \x{00a3} converted to \u00a3
 [2009-04-05 02:41 UTC] avb (Alexey Borzov)
-Status: Analyzed +Status: Closed
This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.