Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>To answer your questions:</p> <ol> <li>On cursory inspection, it does look like your code will strip out malicious data. If you make sure that your code is broken into small functions that operate only on values passed into them as arguments, you can write yourself a command-line-driven test suite that lets you create lots and lots of test cases that you can re-run any time you make changes to the system so that you are confident that no vulnerabilities exist.</li> <li>In general, the slowest part of any web application is the database layer. Poorly crafted queries and/or too many queries will overwhelmingly overshadow PHP code execution in terms of performance issues. In other words, don't worry about over-optimizing your PHP code.</li> <li>Personally, I would improve your code by wrapping everything in a function(). I would also clean <code>$_POST</code> and <code>$_GET</code> values as needed rather than all at once. In other words, I would call <code>clean()</code> on <code>$str</code> in <code>val_rules()</code>. Also, I find it really confusing when using <code>include()</code> or <code>require()</code> to pull in a script and then realizing that that script executes and performs some function "behind the scenes". I think you'll find that using <code>include()</code> or <code>require()</code> works best when the files that are being pulled in are simply used to declare functions, constants, and classes. It is important to be able to clearly follow all execution "out in the open", that is, on the page that is actually doing some work. Similarly, I would not allow the <code>fn_register()</code> function to directly access the <code>$_POST</code> array without passing this in as an argument instead. It's important to be able to look at a function when reading some code and see immediately what data it is acting on without having to look at the function definition. In other words, all data that a function is acting on should ideally be passed in as a value. Finally, and this is a major issue, your name validation is too strict. It will not tolerate hyphens, apostrophes, accented characters, etc. I think you'll find that being liberal in name validation is the best policy. Some culture's naming conventions don't even have what we consider to be first and last names, for example. Another issue: instead of using 'required' and 'optional', use a boolean value for required. If it is set to <code>TRUE</code>, then the field is required.</li> </ol>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload