Is sending data to the same form a good method?

Asked

Viewed 740 times

9

I have a login form, which after given submit he is sent to himself with the information via POST, and if it is wrong, it displays an error message and shows the same form again. I did so to avoid creating type pages: login.php, validalogin.php.

I keep wondering if it was a good method, because I reduced the number of pages, but when the user presses F5 the page re-sends all the data. If this is a good method, it is possible to fix the problem of the F5?

  • 3

    I always use this way too, it is easier to control. You can go through the F5 problem by making your forms with ajax. In addition to avoiding this issue, you give another pro visual face by being able to work the response with error/success messaging callbacks.

  • @Victor Mendonça Only one doubt the Ubmit input remains Submit or becomes type button?

  • 1

    You can leave it as Submit, but then you’ll need to give a false Return in the form onsubmit. It’s easier to put button =)

  • 3

    Please people who read this, use POST. I already registered on site, I put strong password, gave an error, not validated and the password was in the history.

  • 2

    @Gustavorodrigues +1000! Confidential data never shall be transmitted via GET.

  • I also work in this way and agree with Victor who helps the organization. Depending on your situation (script, server and page demand) I wouldn’t worry about the F5 problem, since the form will never be validated. Once the form is validated/processed recommend redirecting (using header ) the user to a confirmation page (which may be the same) to prevent the form from being sent again.

  • A basic tip for forms: associate a function to the 'Submit' button of your form so that it is disabled when clicked. In the reply of the request, if an error occurs it releases the button. If it happens all right, clear the form and release the button.

Show 2 more comments

3 answers

11


Another way around this and also ensure a little more security is to use a Submit token.

Example: When someone asks for the login screen you create a token, example a uuid saves and sends in Hide in the form. Once the form is submitted you check if it exists in your list and mark as used. This way if the same token is returned a few times you won’t reprocess it again.

It starts to improve security too, of course it goes much further than what I expose here, if someone forges the request of your page with a scam, spam whatever else the attacker uses, you will "guarantee" that that form was created by your system "and" that the token used you know it, so it’s a good situation. So if the attacker tries to send it again it will not succeed because the token has already been used.

More about the attack of CSRF

It is good to study the top ten attacks of the OWASP, because there is the problem and a way to solve the problems.

  • +1 Good tip... and I have almost no votes today.

  • 1

    The problem in this case is that if the person goes back to the previous page to reuse the form for a NEW (and valid) entry the UUID will generate a problem.

3

I believe this can be circumvented through a redial. Make a POST for your form and, in case of failure, make a redirect (302) for himself - passing the query string rendering parameters (i.e. which error message to display). So the browser will make a GET for the same form, display the message as you want, and if the user does F5 the browser will simply repeat the GET.

The only drawback, I believe, is that after the F5 the same error messages will be displayed unless you clear the query string via Javascript after the form is displayed.

2

I believe this is a good method.

From the point of view functional, there is no problem in leaving the key F5 resend login data in case authentication fails. The operation is idempotent.

However, from the point of view of usability, maybe it’s best to avoid this and follow @mgibsonbr’s guidance and make a redirect to yourself.

Besides the query string, an alternative already used in other languages for the login failure message to survive one, and only one, redirect is to use the message concept flash. I never used in PHP, but this article has a description of how to implement this.

On the other hand, it is also possible to authentication scheme via Ajax to avoid all this complexity.

When the user clicks on the Submit from the login form, make an Ajax POST call that returns a flag from success or glitch. If failure occurs, show in a field on the screen. If success occurs, make redirection via Javascript to the main page using window.location.href. It is a very simple solution, especially if you use jQuery.

As a bonus, you can also implement both solutions simultaneously, with the Ajax version being added to the form page nonobstructive. If javascript is disabled, login works as "traditional".

Browser other questions tagged

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