Security First

Security should always come first. Multiple attack vectors exist which include, but are not limited to, unauthorized access, cross-site script attack and SQL injection.

The first and initial security step is authorization. When accessing forms that should only be accessed by authorized users, the forms should always be wrapped in authorization checks. Fortunately, frameworks such as Laravel have built in functionality to ensure a user is authorize to have access by wrapping a form with @auth and @endauth tags.

The second is cross-site scripting. A site can spoof a form or site and on submission, steal user information, inject code to gain unauthorized access, etc. Once again, thanks to frameworks, we can mitigate cross-site scriptin functionality. Laravel provides the @csrf tage to be included within a form. The @csrf tage creates a hidden text field with a hashed key value that get stored on the session data. If the hashed value is not included or is wrong on submission, then an error is thrown that indicates a potential cross-site scripting attack.

The remaining steps are done after submission. In order, they are:

1. Authorize: We check to ensure the user is authorized to submit the data being received.
2. Validate: We validate the for data to not only ensure the data matches what is expected for the respective fields, but also to ensure there is no malicious code, such as SQL injections. This is also the step where the cross-site scripting hash is checked.
3. Process: This is where the data has any additional processing needed, either to reformat for storage or fill in information that is not part of the regular form. Email processing or other processes may occur as well.
4. Persist: The data is stored. Whether it is in a table or a file.
5. Return Result or Redirect: Here, we can either return some data that notifies a user through a modal of success or fail or we can redirect the user to a target page showing the results.

 

Switch When You Can!

I am not sure how many times I have seen the excessive use of 'if' statements when a switch is all that is needed.

if ($cond === 'a') {
 ...some a processing...
if ($cond === 'a' && $option === 0) {
 ...some a processing...
 ...option processing...
}
if ($cond === 'b' && $option === 1) {
 ...some processing...
}
if ($cond === 'c') {
 ...some c processing...
}

Running everything through 'if' statements is inefficient, especially with single condition testing. Switches are almost always more efficient and easier to support.

switch ($cond) {
case 'a':
 ...some a processing...
 $option && break; // <-- PHP is a first fail on AND conditions
case 'b':
 if ($option) {
  ...option 1 processing...
 else {
  ...option 0 processing...
 }
 break;
case 'c':
 ...some c processing...
 break;
}