LaravelConf Taiwan 2019 announcement

Tratar con formularios

Otra de las características más potentes de PHP es la forma de gestionar formularios HTML. El concepto básico que es importante entender es que cualquier elemento de un formulario estará disponible automáticamente en sus scripts de PHP. Por favor, lea la sección del manual sobre Variables desde fuentes externas para obtener más información y ejemplos sobre cómo usar formularios con PHP. Observemos un ejemplo:

Ejemplo #1 Un formulario HTML sencillo

<form action="accion.php" method="post">
 <p>Su nombre: <input type="text" name="nombre" /></p>
 <p>Su edad: <input type="text" name="edad" /></p>
 <p><input type="submit" /></p>

No hay nada especial en este formulario. Es solamente un formulario HTML sin ninguna clase de etiqueta especial. Cuando el usuario rellena este formulario y oprime el botón de envío, se llama a la página accion.php. En este fichero se podría escribir algo así:

Ejemplo #2 Mostrar información de nuestro formulario

Hola <?php echo htmlspecialchars($_POST['nombre']); ?>.
Usted tiene <?php echo (int)$_POST['edad']; ?> años.

Un ejemplo del resultado de este script podría ser:

Hola José. Usted tiene 22 años.

Excepto las partes de htmlspecialchars() y de (int), debería ser obvio qué es lo que hace el código. htmlspecialchars() garantiza que cualquier carácter que sea especial en html se codifique adecuadamente, de manera que nadie pueda inyectar etiquetas HTML o Javascript en la página. El campo edad, ya que sabemos que es un número, podemos convertirlo a un valor de tipo integer que automáticamente se deshará de cualquier carácter no numérico. También se puede hacer lo mismo con PHP con la extensión filter. Las variables $_POST['nombre'] y $_POST['edad'] son establecidas automáticamente por PHP. Anteriormente hemos usado la superglobal $_SERVER; arriba introdujimos la superglobal $_POST, la cual contiene todos los datos de POST. Observe que el método de nuestro formulario es POST. Si hubiésemos usado el método GET, nuestra información estaría en su lugar en la superglobal $_GET. También se podría usar la superglobal $_REQUEST, si no le preocupa la fuente de los datos solicitados. Contiene toda la información de los datos de GET, POST y COOKIE mezclada.

En PHP, también puede tratar con entradas de XForms; aunque probablemente al principio se sienta cómodo con los formularios de HTML, los cuales están ampliamente respaldados. A pesar de que trabajar con XForms no es para principiantes, podrían interesarle. Si es así, en la sección de características hay una pequeña introducción a la manipulación de datos recibidos desde XForms.

add a note add a note

User Contributed Notes 3 notes

sethg at ropine dot com
15 years ago
According to the HTTP specification, you should use the POST method when you're using the form to change the state of something on the server end. For example, if a page has a form to allow users to add their own comments, like this page here, the form should use POST. If you click "Reload" or "Refresh" on a page that you reached through a POST, it's almost always an error -- you shouldn't be posting the same comment twice -- which is why these pages aren't bookmarked or cached.

You should use the GET method when your form is, well, getting something off the server and not actually changing anything.  For example, the form for a search engine should use GET, since searching a Web site should not be changing anything that the client might care about, and bookmarking or caching the results of a search-engine query is just as useful as bookmarking or caching a static HTML page.
Johann Gomes (johanngomes at gmail dot com)
8 years ago
Also, don't ever use GET method in a form that capture passwords and other things that are meant to be hidden.
2 years ago
worth clarifying:

POST is not more secure than GET.

The reasons for choosing GET vs POST involve various factors such as intent of the request (are you "submitting" information?), the size of the request (there are limits to how long a URL can be, and GET parameters are sent in the URL), and how easily you want the Action to be shareable -- Example, Google Searches are GET because it makes it easy to copy and share the search query with someone else simply by sharing the URL.

Security is only a consideration here due to the fact that a GET is easier to share than a POST. Example: you don't want a password to be sent by GET, because the user might share the resulting URL and inadvertently expose their password.

However, a GET and a POST are equally easy to intercept by a well-placed malicious person if you don't deploy TLS/SSL to protect the network connection itself.

All Forms sent over HTTP (usually port 80) are insecure, and today (2017), there aren't many good reasons for a public website to not be using HTTPS (which is basically HTTP + Transport Layer Security).

As a bonus, if you use TLS  you minimise the risk of your users getting code (ADs) injected into your traffic that wasn't put there by you.
To Top