Procedures after errors should stay in the services/validations or in the controller?

Asked

Viewed 96 times

1

In a backend that has separate validation functions to check the validity of the data, if this data is invalid the procedure (return a 400 or print something on the screen, for example) must occur in this part of validation or is a task for the controller?

In the frontend where I have a party that handles requests to the server (services), when an error is received from one of these requests, notify the user is the task of the service itself or the controller?

Whose responsibility it is?

simple example with php (the question is not focused on any language, just for example)

main.php:

//Forma 1
isValidPassword("123", "321");

//Forma 2
isValidPassword("123", "321") or die("senhas diferente");

php validation.:

//Forma 1
function isValidPassword($password, $confirm) {
    $password === $confirm or die("senhas diferente");
}

//Forma 2
function isValidPassword($password, $confirm) {
    return $password === $confirm;
}

In frontend the idea is the same, execute a alert() controller or validation function?

validation controller services
  • 1

    William, I couldn’t quite understand your question. But from what I understand, all validation functions as required field, maximum and minimum value, compare fields, should be done at the front end, due to speed and unnecessary sending to your backend, your backend has to be responsible for all processing of your business rule.

  • 1

    I do not agree with what I said, this should be done both on the front (because of ux and non-performance) as on the back, for security reasons, someone could easily create requests with invalid or badly formatted data and the back cannot save these

  • You can apply security to your backend, that only your front can communicate with it, there are several ways to do this. However I agree with Oce regarding not letting invalid data be saved, but if a well constructed security can hardly be a requirement can be passed undesirably

  • Sorry, but @Pauloalexandre is completely wrong. There is no way to know where the request comes from, this is easily forged. Any user can submit any value. You can test this yourself using Curl, for example, so you can send any information. The content analysis, if it is according to what you expect, should be done on the server. Of course, as mentioned, it can also do on the client side, just for the sake of optimizing the user experience.

  • what I say @lnkeliz if Voce places an authentication, it has no way to be called by Curl, only if the person knows how to authenticate to your server.

  • @Pauloalexandre And how will authentication work? What will prevent a traffic monitoring and know how authentication is done? There is no such magic if you are receiving arbitrary content from other people. The only way to "authenticate" would be to have secure hardware that also contains a non-extractable cryptographic key. So the user would send the content to such device and it would sign, if correct. Thus the server would accept, valid signatures, this is similar to FIDO U2F’s "Challenge". However, this is purely unviable.

  • I speak in. NET which is where I have most experience, Voce could put authentication in your whole api, with OAUTH 2.0, as it works in GOOGLE, Voce can only call the Apis if Voce has a valid TOKEN, which is acquired when Voce does a Rest with your user, password and api Voce wants to access

  • @Pauloalexandre this remains useless. OAUTH only says whether or not someone is authorized to make the requisition. However, once you have a valid session, a valid token, Voce can send any request. That is, there is no filter of what may or may not be sent, the server remains responsible for restricting what is valid or not, so the use of "front-end restrictions" is useless, in the security aspect.

  • @Guilherme Costamilam, also do not use $password === $confirm, this is vulnerable to Attack timing. PHP has hash_equals, which compares securely, and better yet, has password_hash.

  • 1

    Thanks @Inkeliz, the code is very basic, just for example

Show 5 more comments

1 answer

3


Code Quality View

From the point of view of the quality of the code, it should use the form 2. The reason arises from two questions that I, the programmer who inherited his code for maintenance, for example, I will make myself considering only the name of its function (without having to look at its code):

  1. What I hope your function isValidPassord do?
  2. What I hope your function isValidPassord return?

Well, by her name, I hope she checks the password is valid and returns true if it is valid and false otherwise. In form 1, function does more than that. It terminates the script if the password is not valid, and this can be a behavior considered unexpected by someone "reading" the code.

Is it wrong? No. Is it desirable? Also not, because this kind of thing (mostly accumulated in large projects) will make it difficult for colleagues or yourself to work and go on vacation (experience demonstrates this, my dear).

UX Point of View

From the UX point of view, validations should be made on the Frontend whenever possible. The reason is that so a user error can be reported much more quickly, without it needing to wait for communication with the server. This is not usually the case for password validation or other things that require searching a database, but it is the case for CPF validations, data formats, etc. Note that I said "whenever possible".

Viewpoint of the Architecture

It’s a good idea to separate validation from any other action (business rules, for example) because you make services (and I’m using generally, validation can also be a service) more atomized and reusable. The atomization, moreover, facilitates the tests and the guarantee that a change in a function X that uses the validation V will not break this another function Y that eventually also use this validation V.

  • If I changed the function name to something clearer, would I have a problem with code quality? Do you have any name suggestions that aren’t too big?

  • 1

    In your example you would change the function to what? How about isValidPasswordOrCommunicateUser? Nothing sounds okay right? Maybe something like ForcePasswordCheck was better, but see that by doing this you only make more visible the low reuse of your function. Again: Wrong? No. It’s good? In my experience it is not, but it really is somewhat debatable... Over time you improve your understanding of it. :)

  • 1

    I forgot to give the reward, mals

Browser other questions tagged validation controller services

You are not signed in. Login or sign up in order to post.