On 17/08/16 21:30, Yasuo Ohgaki wrote: >> 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? > "Direct" means like this? > > $mybool = filter_require_var($_POST['mybool'], FILTER_VALIDATE_BOOLEAN); > > It's possible write code with filter_var()/filter_requrie_var(). It > requires many lines looks mostly the same. > > Anyway, it seems you have strong opinion for your security model. It's > okay to adopt design fits your needs and requirements. For example, > authentication by username & password is weaker than 2 factor > authentication, but it's still acceptable. DbC is excellent way to > build secure and fast apps, but adoption is choice of developers.
Actually I have no objection to your array checker. What I am trying to point out is that POPULATING the array to make your filter work is much better populated from a 'by variable' storage of the full set of rules needed to complete ALL validating checks. MY understanding is that the $_REQUEST array is built from the content of the post message? This involves building a set of variables to work with? I am looking at the dump of a current $_REQUEST and rather than extracting the keys for the array, processing to build your filter rule array, and applying that against the $_REQUEST array, I would prefer that the sort of filtering you are talking about happened prior to creating the variables IN the array ... and one can potentially add the full validation rules to the variables, in the process. What we are differing on is just where unusable data can be ignored, and if you want to kill processing the $_REQUEST array as soon as you detect corruptions in the data why not do that if the first variable CREATED is corrupt? No need to load all the rest of the post/get data? On the other hand one can create all variables and only populate the ones that do have valid data. This is perhaps where the exception model is simply on alternate to an error handling model. In my model I can stop processing the $_REQUEST array if I establish there is an existing record so there is no need to process any of the rest of the post data. Or at least I could if the basic variables had the ability to carry out validation while BUILDING the $_REQUEST array. In exception mode the first exception kills the process. In error mode we simply decide how to handle the problem which may then involve checking what attack mechanism is being used ... or simply say invalid data and reload the the form. If it was just a problem with one field then that field can be ignored while the rest can be mirrored back to the form. -- 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
