Jump to content

displaying errors from server


jimfog

Recommended Posts

I am in the process of writing server validation code in which errors(if found) are sent back to the client with json_encode.

 

My problem has to do with how these errors are going to be displayed in the HTML...

take a look at this HTML:

   <div class="form-group">                    <label>Name:</label><br>                    <input id='name' name="nameinfo"  type="text">                    <p class="fillname"></p>                    <input type="hidden" id="origin" value="backend">   </div>

Here is the server code related with the above-if the user has not filled the above field:

   if($name=='')    {   $noname='you have to put a name';        echo json_encode($noname);    return;    }

How am I going to display the the above message inside <p class="fillname"></p>-my intention as to where the error message I want it to appear?

Link to comment
Share on other sites

That's the developer job to establish and standardize the contract between front and back ends. Consider using a standardized error response that is easy to check on the front end

 

{  "success": false,  "field": "password"  "message: "The password you provided was incorrect"}

 

It's optional if you want your front end messaging to be tied to your backend (ie. returning an error message). If you are strictly doing a RESTful API, you may just want to provide more generic response objects.

 

In this case, the field maps to the POST or GET param, which should make it easy to find the element on the page with the corresponding name

Link to comment
Share on other sites


It's optional if you want your front end messaging to be tied to your backend (ie. returning an error message).

Of course it is optional...but I think server side validation is needed nowadays...and the errors that might arise from it I think they should go to the client and inform the user cause front-end checks might be bypassed.

Link to comment
Share on other sites

Of course it is optional...but I think server side validation is needed nowadays...and the errors that might arise from it I think they should go to the client and inform the user cause front-end checks might be bypassed.

No, that's not what I am saying. What I am saying is the actual messaging, i.e. sending text back from the server like that. It may be preferable to keep that all in the UI layer, and the back end only deals with basic logic / error handling and responding.

Link to comment
Share on other sites

I do not understand...

 

If errors appear in server-side validation should I inform the user about it or not(by sending messages to the client)?

Link to comment
Share on other sites

Do you want to support users who have Javascript turned off? Some error messages will always need to come from the server, such as "Login failed."

No...I do not want to support users that have JS off.

 

Secondly..the error messages I am talking about here have nothing to do with login...they are related with validation.

 

For example....it is a booking app...and the user is called to select from a drop menu some services...in this case I want to validate in the server if the services chosen are indeed contained in the database...if not send a message in the client informing them

Link to comment
Share on other sites

Yes, but what I'm saying is that you obviously DO implement a scheme to return various messages from the server. Now maybe the client-side validation is supposed to catch all the validation errors, so if the server sees a validation error that might indicate a validation code bug or perhaps a hacker. You would still want to return an error message although it might not be as informative as the client-side validation.

 

If the input is suspicious you should also report it to a admin log.

Link to comment
Share on other sites

Yes, but what I'm saying is that you obviously DO implement a scheme to return various messages from the server. Now maybe the client-side validation is supposed to catch all the validation errors, so if the server sees a validation error that might indicate a validation code bug or perhaps a hacker. You would still want to return an error message although it might not be as informative as the client-side validation.

 

If the input is suspicious you should also report it to a admin log.

In the end...what do you propose after all.cause as you said the error might indicate a hacker....

 

showing nothing to the user(which might be a hacker) and report it to a log?

Link to comment
Share on other sites

I guess you would want to cover the possibility that your Javascript validation code has an error, but admittedly a server-side validation error probably indicates someone who has disabled Javascript or a hacker. You might send back a generic "input validation error." You could even count these errors and terminate the session if there are too many of them.

Link to comment
Share on other sites

I do not understand...

 

If errors appear in server-side validation should I inform the user about it or not(by sending messages to the client)?

Yes.

 

But you're not paying attention to what I am saying. I am saying text / language / etc I prefer to keep in the front end / UI realm. Not in the backend API, where there is nothing to know other than business logic. Did it fail? Yes / No. and What failed. boom done. Leave the UI / messaging to the front end.

 

 

That is just a suggestion, and an technical decision you need to decide.

Link to comment
Share on other sites

I guess you would want to cover the possibility that your Javascript validation code has an error, but admittedly a server-side validation error probably indicates someone who has disabled Javascript or a hacker. You might send back a generic "input validation error." You could even count these errors and terminate the session if there are too many of them.

With what you say above you you shed light to a very important aspect.

 

I would say it this way also...if a point has reached where server validation errors appear that might indicate hacker activity...there is no point in informing the hacker about this or that error...I would just log the errors somewhere...and agree with your suggestion that I could terminate the session if there are many errors.

I will consider it.

 

Yes.

 

But you're not paying attention to what I am saying. I am saying text / language / etc I prefer to keep in the front end / UI realm. Not in the backend API, where there is nothing to know other than business logic. Did it fail? Yes / No. and What failed. boom done. Leave the UI / messaging to the front end.

 

 

That is just a suggestion, and an technical decision you need to decide.

I understand now what are you talking about and as you say...it is a decision I will take.

Link to comment
Share on other sites

If the error is in validation of data sent by the user then you definitely need to inform the user about it, whether or not you think they're a hacker. The errors you don't show are parse and runtime errors of the code which may give a clue as to how the code works.

Link to comment
Share on other sites

If the error is in validation of data sent by the user then you definitely need to inform the user about it, whether or not you think they're a hacker. The errors you don't show are parse and runtime errors of the code which may give a clue as to how the code works.

Why I would want to inform the hacker?

To let him know if he succeeded or not?

And as a result try more to achieve his goals.

Link to comment
Share on other sites

Why I would want to inform the hacker?

To let him know if he succeeded or not?

And as a result try more to achieve his goals.

 

You don't understand. All you're telling the user (whether or not he's a hacker) is that the data he sent doesn't fit the criteria you asked him for. What harm do you see in telling them a phone number can't have letters or that the username can't be longer than 50 characters?

 

Having a form not work and not telling the users why it didn't is a good way to lose potential customers.

Link to comment
Share on other sites

I have mixed feelings, but I don't have the experience to tell you what is done in practical applications. You have to consider all of the potential visitors to your site -- the search engine robots, the blind people using screen readers, the people who can't read the language, the various mobile device-types, and develop a reasonable policy of error reporting.

Link to comment
Share on other sites

There's no harm in telling a user the input they entered doesn't fit a valid criteria. (length restriction, number restriction, etc). Lot's application show inline messaging in order to assist users as they fill out a form. However, a best practice for a login form is not to tell them if their username or password is wrong. Only tell them that their login is incorrect, or else hackers will use that as clue to determine if they maybe got one of the two right.

 

What's not safe is to not expect a hacker to try malicious things and not anticipate that. Things like prepared statements aim to make using user supplied data less risky, for example.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...