Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:95254 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 60128 invoked from network); 17 Aug 2016 08:08:15 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Aug 2016 08:08:15 -0000 Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.230 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.230 mail4-3.serversure.net Linux 2.6 Received: from [217.147.176.230] ([217.147.176.230:37481] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E0/D1-45465-C6B14B75 for ; Wed, 17 Aug 2016 04:08:13 -0400 Received: (qmail 10466 invoked by uid 89); 17 Aug 2016 08:08:09 -0000 Received: by simscan 1.3.1 ppid: 10451, pid: 10463, t: 0.1175s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 17 Aug 2016 08:08:08 -0000 To: internals@lists.php.net References: Message-ID: Date: Wed, 17 Aug 2016 09:08:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: [RFC][VOTE] Add validation functions to filter module From: lester@lsces.co.uk (Lester Caine) On 17/08/16 03:59, Yasuo Ohgaki wrote: > require_once('my_exception_error_handler.php'); Actually load framework ... and that is the first can of worms? > require_once('my_input_spec_def_for_this_file.php'); THIS is my sticking point ... What it needs to load is the rules for all of fields that were in the page build. For simple forms that is fine, but it does not scale. For more complex form it has to scan the input array and build a list of keys ... why not carry out checks while doing that scan? Makes building an array of rules pointless, just use the individual rules ... except we do not know where to get them. > // Validate general requirement that cannot covered by filter_requrie*() > validate_inputs(); > // These are came from this RFC. Validate inputs. > // What's to validate is design decision, but validating them all is the > // best way. > filter_require_var_array($_GET, $get_spec); > filter_require_var_array($_POST, $post_spec); > filter_require_var_array($_COOKIE, $cookie_spec); > filter_require_var_array($_SERVER, $server_spec); I have less of a problem with the STATIC stuff covered here EXCEPT that would be handled as part of loading the framework and include checking what state of handling the form you ARE at. In my case the session has elements of handling multiple page forms. > session_start(['use_csrf_protection'=>1]); // There is RFC for this. > > function check_user_input_error($today) { > if (strtotime($today) != date('Ymd')) { > $err_msg[] = 'You have entered invalid date. '. $today; > return $err_msg; > } > } I will not waste time going through your long discussion on handling dates it's the bain of my life! Especially when you get given 12/8/2016 and have no idea if it is August or December! So forms use date pickers and browser validation. And the "'You have entered invalid date. '. $today;" forms part of the set of rules used to build the form. Validate that christening date is later than birth date has a suitable error message as part of that rule set. Now cross checking those rules at this stage is probably necessary but only if some hacker is trying to be cleaver? But in my case business rules can be cross checked in the database ... apps other than PHP may also be accessing it ( think pigging phone apps :( ) ... so the same rules are needed in the database business logic. And that is why populating the PHP rules data from the database schema makes sense. > Simple web forms should be able to be written by PHP core feature > only. IMHO. Just how many versions of 'login' or 'register' pages exist and all have checks for valid username, password and email. And all use different styles of managing the rules. > It's impossible to teach beginners how to write code for input validations. > As a result, the most important security feature, input validation, is > omitted in beginner courses/examples/etc. > > It's great for beginners to understand what's going on Web apps and > what developers should do. It's useful for small web service that > requires the best performance possible as well. We are on the same book, just coming at this from different ends. It's that 'my_input_spec_def_for_this_file.php' which is the problem starting with just where you get the set of rules from and not having a simple beginner friendly method of adding those rules to a variable. There are hundreds of legacy examples of how to do a login form, and the vast majority use styles of programming that start a user down the wrong path from day one ... so can we agree on something simple and easily expandable? filter_require_var_array($_POST, $post_spec); could then use those rules to build the $post_spec array, but why not just use the rules direct? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk