On 17/08/16 03:59, Yasuo Ohgaki wrote:
> <?php
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
