Processing a user-filled form: how to reduce code complexity?
While working on writing administrative, and user interface, I often found myself thinking - and do I do everything so that with a minimum of effort to ensure optimal quality?
Today I would like to discuss the issue of processing form input errors in web applications. How do you still completely trust the user input data and consider the creature on the other side of the monitor being a sacred cow? Do not worry, it will pass after the first attack, if the principles of input control will not become clear to you earlier. However, to the point.
I program in PHP, so server code examples will be in this language.
')
Imagine that we decided to supplement your project with a form for ordering a callback. You never know - the lines are often overloaded, the client wants to feel his weight, this fashion ... well, in general it is necessary. Quickly throw in the simplest html, write a handler - the data is beautifully formed into the database, in general - almost done. It remains to do just a little - write error handling. (Of course, the order of development is very conditional). How can this check the user input for correctness and notify him of the result?
In the case of a properly completed form of work at least. But if the user made a mistake and the data is incorrect, you are forced to re-generate the page and send it to the user. At the same time, it is highly desirable to save the values of all filled fields, which increases your code.
Consider the basic error handling (we believe that user data has already passed the basic checks and filtering):
We want to bring some convenience to the client. And we come to the rescue ...
The alert function is used only as an educational example, according to statistics, some users will close it without reading it, because it is displayed in the OS design and is not perceived as part of the web page.
Once again, I’ll draw your attention to the fact that server verification is still necessary.
Every time when I am asked to tell why it is needed, I remember about the year 2004, when I, a novice web developer, met by correspondence with a nice guy from Ukraine, who was then the author of his own CMS. Trying to learn from experience, I somehow asked him how he handles errors. It turned out that he does this only with the help of JavaScript. It was necessary to share the experience that you can save the page to your computer, change the address of the form handler and send data without validation. And if validation is not already on the server, incorrect data will be perceived as normal, and then everything will depend on the application logic. Later in the process, I often encountered similar vulnerabilities. The conclusion suggests itself - if a web application is written without an understanding of the interaction between the client browser and the server, the result may be different.
Time passes, the complexity of the forms grows and I turn my attention to the following technology.
Now, for convenience, the check is placed in a separate method and is a little added, as a result we get something like this code:
Further, in the client's browser, we can show the same alert or display a message in any other way convenient for us. Usability is up to the mark - no page reload is required, the convenience of further support of the code is also the same - all error handling is collected in one place.
As long as the form consists of a small number of fields, it is not so difficult when adding the next field to modify the output after receiving erroneous data. And if there is a lot of data? In this case, there is a desire to facilitate the work for yourself and to abandon such full support for the old browsers, removing the output and getting the following code:
We have significantly simplified our work to further support the code, while deliberately abandoning the full support of devices with disabled JavaScript. Something had to sacrifice for the sake of their own convenience. But this approach is not justified if the emphasis is on the quality of development.
At the moment I continue to experiment with data checks. Still looking for the perfect solution that would be even more optimal. I am pleased to hear criticism and discuss all aspects of various approaches with readers.
Today I would like to discuss the issue of processing form input errors in web applications. How do you still completely trust the user input data and consider the creature on the other side of the monitor being a sacred cow? Do not worry, it will pass after the first attack, if the principles of input control will not become clear to you earlier. However, to the point.
I program in PHP, so server code examples will be in this language.
')
Imagine that we decided to supplement your project with a form for ordering a callback. You never know - the lines are often overloaded, the client wants to feel his weight, this fashion ... well, in general it is necessary. Quickly throw in the simplest html, write a handler - the data is beautifully formed into the database, in general - almost done. It remains to do just a little - write error handling. (Of course, the order of development is very conditional). How can this check the user input for correctness and notify him of the result?
In the case of a properly completed form of work at least. But if the user made a mistake and the data is incorrect, you are forced to re-generate the page and send it to the user. At the same time, it is highly desirable to save the values of all filled fields, which increases your code.
Consider the basic error handling (we believe that user data has already passed the basic checks and filtering):
<?php $errors = array(); if ( empty($person) || empty($phone) || empty($question) ) { $errors[] = ' '; } if ( count($errors) ) { $template->assign_switch('errors', 1); $template->vars(array( 'ERRORS' => implode(' ', $errors), 'PERSON' => $person, 'PHONE' => $phone, 'QUESTION' => $question ) ); $template->send(); } ?> We want to bring some convenience to the client. And we come to the rescue ...
Javascript
<script language="text/javascript"> <!-- // function form_submit() { if ( ( document.forms['callback'].person.value == '' ) || ( document.forms['callback'].phone.value == '' ) || ( document.forms['callback'].question.value == '' ) ) { alert(' '); } return; } // --> </script> The alert function is used only as an educational example, according to statistics, some users will close it without reading it, because it is displayed in the OS design and is not perceived as part of the web page.
Once again, I’ll draw your attention to the fact that server verification is still necessary.
Every time when I am asked to tell why it is needed, I remember about the year 2004, when I, a novice web developer, met by correspondence with a nice guy from Ukraine, who was then the author of his own CMS. Trying to learn from experience, I somehow asked him how he handles errors. It turned out that he does this only with the help of JavaScript. It was necessary to share the experience that you can save the page to your computer, change the address of the form handler and send data without validation. And if validation is not already on the server, incorrect data will be perceived as normal, and then everything will depend on the application logic. Later in the process, I often encountered similar vulnerabilities. The conclusion suggests itself - if a web application is written without an understanding of the interaction between the client browser and the server, the result may be different.
Time passes, the complexity of the forms grows and I turn my attention to the following technology.
AJAX
Now, for convenience, the check is placed in a separate method and is a little added, as a result we get something like this code:
<?php $errors = array(); if ( empty($person) || empty($phone) || empty($question) ) { $errors[] = ' '; } $ajax = isset($_REQUEST['ajax']); if ( count($errors) ) { if ( empty($ajax) ) { $template->assign_switch('errors', 1); $template->vars(array( 'ERRORS' => implode(' ', $errors), 'PERSON' => $person, 'PHONE' => $phone, 'QUESTION' => $question ) ); $template->send(); } else { $ajax_handler->send(array( 'errors' => 1, 'error_text' => implode(' ', $errors), ) ); } } else { $ajax_handler->send(array( 'errors' => 0, 'error_text' => '', ) ); } ?> Further, in the client's browser, we can show the same alert or display a message in any other way convenient for us. Usability is up to the mark - no page reload is required, the convenience of further support of the code is also the same - all error handling is collected in one place.
Bad advice
As long as the form consists of a small number of fields, it is not so difficult when adding the next field to modify the output after receiving erroneous data. And if there is a lot of data? In this case, there is a desire to facilitate the work for yourself and to abandon such full support for the old browsers, removing the output and getting the following code:
<?php if ( count($errors) ) { if ( empty($ajax) ) { header('Location: form.php?error_code=1'); exit(); } } ?> We have significantly simplified our work to further support the code, while deliberately abandoning the full support of devices with disabled JavaScript. Something had to sacrifice for the sake of their own convenience. But this approach is not justified if the emphasis is on the quality of development.
Conclusion
At the moment I continue to experiment with data checks. Still looking for the perfect solution that would be even more optimal. I am pleased to hear criticism and discuss all aspects of various approaches with readers.
Source: https://habr.com/ru/post/132805/
All Articles