Ver índice
Utilizando formularios

        Ocultar índice  

   Índice de contenidos
   Instalación en Windows
   Instalación en Ubuntu
   Servidores seguros
   Páginas dinámicas
   Sintaxis básica
   Operaciones
   Arrays
   Formatos de presentación
   Operadores
   Bucles
   Extraer y ord. información
   Funciones
   Ficheros externos
   Imágenes dinámicas
   Gestión de directorios
   Cookies y sesiones
   Clases y objetos
   Ficheros en formato PDF
   Bases de datos MySQL
   PHP y XML
   PDO - Bases SQLite / MySQL
   MySQL a traves de misqli
   Algo de JavaScript y AJAX


PHP dinámico

Hasta el momento, PHP sólo nos ha servido para escribir una serie de scripts y ver los resultados de su ejecución pero aún no hemos hecho mención alguna a la manera en la que puede establecerse un diálogo (interacción) entre cliente y el servidor que, en definitiva, es la razón de ser de las páginas dinámicas.

Cuando se trata de páginas estáticas la comunicación está muy restringida. El cliente hace una petición (escribe el nombre de una página en la barra de direcciones del navegador) y el servidor se limita a devolver los contenidos de esa página. Un primer paso para mejorar es esa comunicación será que el cliente especifique algo más en su petición y que el servidor interprete esa información complementaria. Ese algo más puede incluirse en la barra de direcciones con la siguiente sintaxis:

pagina.php?nombre1=valor1&nombre2=valor2, ...

dónde pagina.php es la dirección de una página que contiene scripts PHP y dónde ? es un carácter obligatorio que indica que detrás de él se incluye más información. Esa información estará formada por parejas nombre - valor enlazadas por un signo = y separadas entre sí por el símbolo &.

De esa forma el servidor entendería la petición de la siguiente forma: Vete a la página pagina.php, mira los scripts PHP, asigna a las variables nombre1, nombre2 etcétera los valores valor1, valor2,... ejecuta los scripts con esos valores y devuélveme los resultados.

Observarás que los nombres de las variables nunca llevan el signo $ y que los valores de las variables –sean números o cadenas– tampoco se escriben nunca entre comillas.

Algunos caracteres especiales (& por ejemplo) no pueden escribirse directamente dado que se prestan a confusión dando lugar a la duda de si habrían de intepretarse como un valor como el símbolo de unión. En esos casos es necesario sustituir el carácter por su codificación URL que representa cada carácter anteponiendo el signo % al valor de su código ASCII expresando en formato hexadecimal. En este enlace tienes una tabla de conversión.

Se pueden incluir tantos nombre = valor como se desee. La única restricción es la longitud máxima permitida por el método GET (el utilizado en este caso) que se sitúa en torno a los 2.000 caracteres.

Recepción de datos

Cuando es recibida por el servidor la petición de un documento con extensión .php en la que tras el signo ? se incluyen una o varias parejas nombre = valor, los nombres de las variables y sus valores respectivos se incluyen siempre, de forma automática, en variables predefinidas de dos tipos:

$_GET['nombre1']=valor1, $_GET['nombre2']=valor1, etcétera, en las que nombre1, nombre2, ... coinciden exactamente con nombres especificados en las petición y los valores asignados a estas variables también coinciden con los recibidos, junto con cada nombre, a través de la petición.

$_REQUEST['nombre1']=valor1, $_REQUEST['nombre2']=valor1 recoge los mismos valores que la anterior $_GET. Esta aparente duplicidad de información tiene una funcionalidad añadida que veremos un poco más adelante

La variables anteriores tienen una sintaxis un poco engorrosa. Por eso, las versiones más recientes de PHP incluyen una nueva función que puede agregar algo de funcionalidad. Es la siguiente:

extract(array asociativo)

que crea de forma automática variables con los nombres de todos los indices del array les asigna el valor de ese elemento del array. Es decir, si hemos recibido valores como $_GET['nombre1']=7 y $_GET['nombre2']='pepe' e incluimos en el script la función extract($_GET) PHP creará de forma automática las variables $nombre1=7 y $nombre2='pepe'.

Mediante extract($_REQUEST) obtendrían los mismos resultados. En definitiva, la función extract() no hace otra cosa que crear variables PHP con idéntico nombre al indicado en la petición.

Hay configuraciones de PHP en las que no es necesario utilizar la función extract(). Cuando el fichero php.ini tiene configurada la directiva register_globals=ON las variables del tipo: $nombre1=valor1, $nombre2=valor2, etcétera se crearían de forma automática al ser recibida la petición del cliente.

  ¡Cuidado!  

La directiva register_globals ha evolucionado mucho a través de las distintas versiones de PHP. En las versiones más antiguas venía configurada, por defecto, con el valor ON. Actualmente viene configurada, también por defecto como OFF y se comenta que en futuras versiones de PHP su valor seguirá siendo OFF pero ya no será posible modificarla.
Por ello, quizá lo más prudente escribir nuestro código pensando siempre que su configuración es OFF y además es inmodificable.

Veamos algunos ejemplos.

<?php
/* Empezaremos utilizando
   $_GET['a'], $_GET['b' */
# Pongamos un comentario de advertencia. Recuerda que <br>
# sirve para insertar un salto de línea en la salida
print ("Este resultado es el que utiliza \$_GET<br>");
print ($_GET['a']." x ".$_GET['b']." = ".$_GET['a']*$_GET['b']);
/* Ahora trataremos de comprobar que también podemos
    utilizar la superglobal $_REQUEST como $_REQUEST['a'] y $_REQUEST['b']
	con iguales resultados que las anteriores */
# Un comentario para identificar el origen del resultado
print("<br>El resultado siguiente ha sido generado usando \$_REQUEST <br>");
print $_REQUEST['a']." x ".$_REQUEST['b']." = ";
print $_REQUEST['a']*$_REQUEST['b'];
?>
ejemplo19.php ejemplo20.php

Si pulsas el enlace del ejemplo19 verás que te aparece una retahila de mensajes de advertencia. Es lógico que así sea. El script necesita los valores de las variables $a y $b. Como no recibe nada los ha de considerar con valor cero y, a la vez, dado que PHP tiene configurada la gestión de errores de forma muy estricta nos advierte que esas variables no han sido inicializadas.

Si escribieras ejemplo19.php?a=21&b=456 todo funcionaría correctamente. No habría lugar al mensaje de advertencia porque las variables ya tienen contenido.

Para evitar la visualización de los mensajes de advertencia existen diferentes posibilidades. Además de las mencionadades cuando estudiábamos las variables –las tienes comentadas en este enlace– tenemos la opción de modificar el script anteponiendo a las instrucciones print (las que pueden dar el mensaje de error cuando se ejecuten sin asignar valores a las variables) el símbolo @. Mediante ese símbolo (@) inhibimos la aparición del mensaje de error al ejecutarse la instrucción a la que precede. Eso es lo que hemos hecho en el ejemplo20. Verás que al ejecutarlo (aquí está su código fuente) ya no aparece el mensaje de error.

Como es lógico, al asignar valores a las variables escribiendo en la barra de direcciones del navegador la siguiente dirección: ejemplo20.php?a=21&b=456, (o pulsemos directamente en este enlace) el resultado no diferiría en nada del obtenido con el ejemplo19.

  ¡Cuidado!  

Aquí, más que nunca, conviene reiterar, una vez más, los errores de sintaxis más frecuentes:
  • Los nombres de variables son distintos si se cambian mayúsculas y minúsculas. Pon mucho cuidado en escribirlos correctamente.
  • Los nombres de las variables predefinidas, tales como $_GET, etcétera van en mayúsculas.
  • No olvides poner punto y coma al final de cada línea de instrucciones.
  • Presta atención a la apertura/cierre de comillas y mucha más atención aún si se trata de comillas anidadas. En este caso procura usar (") para las exteriores y (') para las interiores.

Probemos otras de las opciones. Utilicemos la función extract para leer los datos recibidos.

<?php
/* al incluir extract se crearán variables automáticas
   con los nombres incluidos a través de la barra de direcciones
   del navegador */
extract($_GET);
/* Escribamos una instrucción, que imprima en pantalla
   el valor de una de las variables extraidas ($a),
   una "x" que hará funciones de aspa
   en la presentación, otra variable ($b), el signo igual
   y $a*$b que es el producto de ambas variables
   El  simbolo de multiplicar es (*)
   anteponemos al print el simbolo @ para evitar
   que aparezca mensaje de error por variable no definida  */
@print ($a." x ".$b." = ".$a*$b);
# Añadamos una bobadilla, para animar... ;-)
print ("<br> ¡¡Acabamos de usar la función extract!!");
?>
ejemplo21.php ejemplo22.php

Ejecuta este ejemplo (no aparecerán mensajes de advertencia porque hemos incluido los @ que los inhiben) y observa lo que aparece. ¿Sólo x =0? ¿y la otra línea?

El resultado es lógico. No hemos asignado valores a las variables $a y $b y por eso no escribió su valor. Sin embargo, a la hora de multiplicar -recuerda que una variable vacía es interpretada como cero a la hora de hacer operaciones– la interpretó como cero y –con muy buen criterio– nos respondió que cero por cero es cero.

Escribamos ahora la dirección: ejemplo21.php?a=13&b=7, (también puedes pulsar en este enlace) y podremos comprobar que 13 x 7 = 91 . Observa también que ahora no aparece ningún mensaje de error porque hemos antepuesto @ a la instrucción print.

Hagamos un nuevo experimento. Probemos ejemplo22.php?a=13&b=7 y veamos que el resultado no es el esperado. El ejemplo22 es muy similar al ejemplo21 (puedes ver aquí su código fuente) pero tiene una diferencia importante. Hemos comentado la línea que contiene la función extract. Por tanto esta ya no se ejecuta. Lo que realmente ocurre es que no lee los valores de las variables $a y $b porque para poder leerlas directamente se requería que la directiva register_globals de php.ini estuviera ON y, por defecto, esta directiva viene configurada como register_globals=Off.

Si pruebas a cambiar esa configuración, reinicias el servidor y pulsas de nuevo en el enlace, verás que esta vez si ha recibido los valores de a y b y nos ha dado el resultado de la operación.

  ¡Cuidado!  

En modo local puedes establecer las configuraciones de php.ini a tu antojo que te permite utilizar cualquiera de las opciones de transferencia de variables.
Pero, si pretendes publicar tus páginas utilizando un hosting ajeno debes usar la opción de mayor compatibilidad se son, sin duda alguna, $_GET, ó $_REQUEST complementadas, si lo estimas más cómodo con la función extract.
Ten en cuenta que allí no vas a poder modificar las configuraciones y de no tener en cuenta estos aspectos, puedes verte obligad@ a modificar tu código fuente para adecuarlo a la configuración de tu hosting.

Envío a través de formularios

La interacción cliente–servidor que acabamos de ver resulta incómoda en su uso y no demasiado estética.

Hay una segunda opción –la de uso más frecuente– que es la utilización de formularios que no son elementos propios de PHP –actúan del lado del cliente– siendo su estudio es más propio del ámbito de HTML que de PHP. No obstante –por si te fuera necesario– aquí tienes un formulario, en el que se comenta la sintaxis de sus elementos más comunes.

Un ejemplo formulario

 
<html>
<head>
</head>
<body>
<!-- Un formulario debe empezar siempre con una etiqueta de este tipo <form ...>
       dentro de la cual obligatorio indicar con esta sintaxis action='nombre.extension'
       el nombre de la página destinataria de la información que se incluya en el formulario.
       nombre.extension debe contener el nombre (o la ruta completa en el caso de que estuviera
       en un directorio o hosting distinto del que alberga el documento que contiene el formulario
       desde el que se realiza la petición)

       Es opcional incluir (también dentro de la etiqueta <form ...>) method que puede
       tener dos valores method='GET' ó method='POST'
       Por defecto (cuando no se indica) se interpretará que method='GET'

       También es opcional -a los efectos de PHP- incluir name.
       Ese valor es útil cuando se incluyen scripts del lado del cliente del tipo JavaScript  //-->

<form name='mi_formulario' action='ejemplo26.php' method='post'>
<!-- Pueden incluirse textos dentro del formulario -->
Escribe tu nombre:

<!-- Uno de los tipos de campos posibles es el tipo texto. Su sintaxis (hablamos de HTML)
       requiere la etiqueta <input type='text'> que indica que el contenido será  texto.
       Esta etiqueta debe incluir obligatoriamente un name='nombre' en el que pueden usarse
       caracteres alfabéticos, sin tildes ni eñes y sin espacios. Salvo excepciones que veremos
       más adelante el nombre ha de ser único y distinto para cada elemento del formulario.

       También dentro de la etiqueta <input type='text'> puede incluirse value='' que puede
       no contener nada tal como ocurre aquí o contener el texto que, por defecto,
       queremos que aparezca en ese campo al cargar el formulario.
	   También puede conteenr (es opcional) size=xx. Su utilidad es la de ajustar el
	   tamaño de la ventana al número de caracteres que se indiquen mediante xx //-->

<input type='text' name='nombre' value='' size=15><br>
Escribe tu clave:

<!--  <input type='password'> solo se diferencia del anterior en que en el momento de rellenarlo
      se sustituyen los carecteres visualizados (no el contenido) por asteriscos //-->

<input type='password' name='clave' value=''><br>
Elige tu color de coche favorito:<br>

<!--  Los <input type='radio'> permite optar entre varios valores posibles.
      Habrá que repetirlos tantas veces como opciones queramos habilitar.
	  Todos los input –correspondientes a la misma opción– deben tener el mismo nombre (name)
	value='xxxxx' deberá tener un valor distinto en cada uno de ellos.
     El valor (loquesea) de la opción marcada es que será transferido a través del formulario
	Si queremos que una opción aparezca marcada (por defecto)al cargar el formulario,
    deberemos incluir en su etiqueta la palabra checked
	Los contenidos de value no se visualizan en el navegador  por lo que conviene incluir
    una descripción de los valores después de cerrar la etiqueta de cada uno de esos input.
	Al enviar el formulario solo se transmite el value de la opción seleccionada   //-->

<input type='radio' name='color' value='Rojo'>Rojo</br>
<input type='radio' checked name='color' value='Verde'>Verde</br>
<input type='radio' name='color' value='Azul'>Azul</br>
Elige los extras:<br>

<!--  Cada uno de los <input type='checkbox'> requiere un nombre distinto (name) y un valor (value)
	 Pueden marcarse uno, varios, todos o ninguno. Si queremos que una casilla aparezca marcada
     (por defecto) al cargar el formulario, deberemos incluir en su etiqueta  la palabra checked
     Solo serán transferidos a través del formulario los nombres y valores de aquellos
     cuya casilla esté marcada.
	 Los contenidos de value no se visualizan en el navegador por lo que conviene incluir
     una descripción de los  valores después de cerrar la etiqueta de cada input  //-->

<input type='checkbox' name="acondicionado" value="Aire">Aire acondicionado<br>
<input type='checkbox' checked name="tapiceria" value="Tapicieria">Tapiceria en piel<br>
<input type='checkbox' name="llantas" value="aluminio">Llantas de aluminio<br>

<br>¿Cual es el precio máximo que estarías dispuesto a pagar?

<!-- La etiqueta <input type='select'> requiere un nombre y  una etiqueta de cierre </select>
	 Entre ambas -apertura y cierre- deben incluirse las diferentes opciones
	 entre las etiquetas <option>valor<option>
 	Al enviar el formulario se transmite lo contenido después de opción en la seleccionada
    salvo que dentro de la propia etiqueta opción se incluya un value.
    Si dentro de una etiqueta option  escribimos selected será esa la que aparezca seleccionada
    ,por defecto, al cargarse el formulario//-->

<select name="precio">
<Option>Menos de 6.000 euros</option>
<Option>6.001 - 8.000 euros</option>
<Option selected >8.001 - 10.000 euros</option>
<Option value=11634.52>10.001 - 12.000 euros</option>
<Option>12.001 - 14.000 euros</option>
<Option>Más de 14.000 euros</option>
</select>
<!-- Las áreas de texto deben tener una etiqueta de apertura <textarea name='checkbox'> seguida de una etiqueta de cierre </textarea> Dentro de la etiqueta de apertura puede incluirse rows=xx (indicará el número de filas) cols=yy (indicará el ancho expresado en número de caracteres) y opcionalmente un value='lo que sea...' que puede contener el texto que -por defecto- pretendemos que aparezca en ese espacio al cargar el formulario //--> <br> Escribe aquí cualquier otro comentario:<br> <textarea rows=5 cols=50 name='texto'></textarea><br> <!-- El <input type='hidden'> permite insertar en un formulario una valor oculto que no requiere ser cumplimentado por el usuario y que no aparece visible en el documento. Requiere un name y un value //--> <input type="hidden" name='oculto' value='Esto iría oculto'><br> <!-- El <input type='submit'> es el encargado de ejecutar la action incluida en la etiqueta de apertura del formulario. Sería la llamada a la página que se indica en la action El texto que se incluya en su value será el que se visualice en el propio botón de envio //--> <input type="submit" value="enviar"> <!-- El <input type='reset'> permite borrar todos los contenidos del formulario y reestablecer los valores por defecto de cada campo //--> <input type="reset" value="borrar"> <!-- La etiqueta </form> es la etiqueta (obligatoria) de fin del formulario //--> </form> </body> </html>

Interpretación de los datos recibidos a través de formularios

Igual que ocurría en el caso anterior, los datos enviados a través de un formulario son recogidos en diferentes tipos de variables predefinidas. Ahora se añade una nueva particularidad. Existe la posibilidad de dos métodos (method) de envío: GET o POST. En el caso anterior decíamos que se utilizaba el método GET, pero en el caso de los formularios son posibles ambos métodos. Conviene tenerlo en cuenta.

Método GET

No se diferencia en nada de lo descrito para el supuesto anterior. Utiliza las mismas variables predefinidas ($_GET y $_REQUEST), las utiliza con idéntica sintaxis y se comporta de igual forma en lo relativo a las opciones de register_globals.

Los nombres de las variables son en este caso, los incluidos como name en cada una de las etiquetas del formulario.

Respecto a los valores recogidos del formulario serían los siguientes. En los casos de campos tipo: text, password y textarea serían los valores introducidos por el usuario en cada uno de ellos.

En el caso de los campos tipo radio –en el que varias opciones pueden tener el mismo nombre– recogería el valor indicado en la casilla marcada; mientras que si se trata de campos tipo checkbox se transferirían únicamente las variables –y los valores– que corresponden a las casillas marcadas.

Si se tratara de un campo oculto –tipo hidden– se transferiría el valor contenido en su etiqueta y, por último, en el caso del select sería transferido como valor de la variable la parte del formulario contenida entre las etiquetas <option></option> de la opción seleccionada salvo que, dentro de la propia etiqueta option se incluya un valor mediante value=xxxxx.

Método POST

En el caso de que el método de envío sea POST hay una diferencia a tener en cuenta en cuanto a las variables que recogen la información. Ahora será la variable superglobal $_POST['nombre'] la que reemplace a $_GET['nombre'] usado en el caso del método GET.

Si register_globals está en On el comportamiento de las variables directas es idéntico al comentado para el caso de GET.

La opción REQUEST

La variable superglobal $_REQUEST['nombre'] aúna las funcionalidades de $_GET y $_POST y que recoge tanto los valores transferidos mediante el método GET como mediante POST.

Identificación del método de envío

PHP recoge en una variable el método utilizado para enviar los datos desde un formulario. Se trata de la variable:

$_SERVER['REQUEST_METHOD']

que devuelve una cadena (GET ó POST) que especifica el método de envío utilizado.

Diferencias ente los métodos GET y POST

Las diferencias entre uno y otro método son las siguientes:

Método GET
Método POST

Tipos de contenidos de los formularios

Vamos a contemplar un último aspecto relativo a los formularios. Se trata de la forma de codificar los datos para su transmisión (ENCTYPE). Puede especificarse dentro de la etiqueta<form> utilizando la sintaxis: enctype='valor'.

En el caso de que no se especifique, tomará el valor application / x-www-form-urlencoded, sea GET o POST el método que se utilice.

ENCTYPE admite también el valor multipart/form-data como una opción alternativa a la anterior.

Las diferencias básicas entre ambos modos de codificación son las siguientes:

  ¡Cuidado!  

Cuando se incluye una cadena vacía ("") como valor de action en un formulario se recargará el mismo documento como respuesta al envío del formulario.

Ejemplos de las diferentes opciones de formularios

Intentaremos ver ejemplos de las diferentes opciones. Utilizaremos un formulario idéntico al descrito anteriormente dónde incluiremos como action una llamada al script ejemplo26.php (su código fuente es el que puedes ver aquí debajo) y donde dónde no especificaremos ningún valor para ENCTYPE con lo cual asumirá su valor por defecto, application / x-www-form-urlencoded

En el código fuente que ves aquí debajo intentamos leer los contenidos transferidos utilizando las diferentes posibilidades que nos ofrece PHP. Incluimos dos ejemplos cuya una única diferencia el método utilizando en el formulario. En el primero de ellos se utiliza el método GET y en el segundo POST.

<?php
print "Empezaremos comprobando el método de envío";
print " El method que ha usado fué: ".$_SERVER['REQUEST_METHOD']."<br>";
print "Leeremos los contenidos de la superglobal \$_REQUEST";
print " Funcionará tanto con el método GET como con POST"."<br>";
@print $_REQUEST['nombre']."<br>";
@print $_REQUEST['clave']."<br>";
@print $_REQUEST['color']."<br>";
@print $_REQUEST['acondicionado']."<br>";
@print $_REQUEST['tapiceria']."<br>";
@print $_REQUEST['llantas']."<br>";
@print $_REQUEST['precio']."<br>";
@print $_REQUEST['texto']."<br>";
@print $_REQUEST['oculto']."<br>";
print "Ahora leeremos los contenidos de la superglobal \$_POST";
print " Sólo dará resultados cuando el método sea POST"."<br>";
@print $_POST['nombre']."<br>";
@print $_POST['clave']."<br>";
@print $_POST['color']."<br>";
@print $_POST['acondicionado']."<br>";
@print $_POST['tapiceria']."<br>";
@print $_POST['llantas']."<br>";
@print $_POST['precio']."<br>";
@print $_POST['texto']."<br>";
@print $_POST['oculto']."<br>";
print "Ahora leeremos los contenidos de la superglobal \$_GET";
print " Sólo dará resultados cuando el método sea GET"."<br>";
@print $_GET['nombre']."<br>";
@print $_GET['clave']."<br>";
@print $_GET['color']."<br>";
@print $_GET['acondicionado']."<br>";
@print $_GET['tapiceria']."<br>";
@print $_GET['llantas']."<br>";
@print $_GET['precio']."<br>";
@print $_GET['texto']."<br>";
@print $_GET['oculto']."<br>";
print "Ahora intentaremos leer variables directas" ;
print " Sólo dará resultados cuando REGISTER_GLOBALS=On"."<br>";
@print $nombre."<br>";
@print $clave."<br>";
@print $color."<br>";
@print $acondicionado."<br>";
@print $tapiceria."<br>";
@print $llantas."<br>";
@print $precio."<br>";
@print $texto."<br>";
@print $oculto."<br>";
print "Incluyamos la función extract aplicada a \$_REQUEST";
print " de esa forma dará resultados tanto cuando el método sea GET como cuando sea POST. ";
print " Si la hubiéramos aplicado \$_POST solo funcionaría con ese método.";
print " Si lo hubiéramos hecho \$_GET solo atendería ese método"."<br>";
extract($_REQUEST);
@print $nombre."<br>";
@print $clave."<br>";
@print $color."<br>";
@print $acondicionado."<br>";
@print $tapiceria."<br>";
@print $llantas."<br>";
@print $precio."<br>";
@print $texto."<br>";
@print $oculto."<br>";
?>
«Con method = POST» «Con method = GET»

Estos dos nuevos ejemplos son modificaciones de los anteriores. Ahora hemos incluido dentro de la etiqueta <form> la opción ENCTYPE="multipart/form-data" manteniendo el resto del formulario sin ninguna modificación.

«Con method = POST» «Con method = GET»

La seguridad en los envíos de datos

El tema de la seguridad es una preocupación constante entre los usuarios de Internet. Cuando utilizamos las técnicas que venimos comentando en esta página –nos referimos siempre al caso de servidores remotos– corremos dos tipos de riesgo de seguridad que no estaría de más tener en cuenta.

El riesgo de que la información sea interceptada durante el proceso de transmisión desde el cliente hasta el servidor lo compartimos con todos los demás usuarios de la Red, pero hay otro –el riesgo de daños en los contenidos de nuestro espacio de servidor– que es exclusivamente nuestro.

La transparencia del método GET es tal, que incluso muestra –en el momento del envio– todos los datos en la barra de direcciones del navegador. Eso permite que cualquier usuario pueda conocer a simple vista la ruta completa hasta el script, así como los nombres y valores de las variables.

Cuando se usa el método POST los formularios son un poco más discretos, pero igual de transparentes. El código de cualquier formulario estará accesible sólo con ir a la opción Ver código fuente y allí estarán de nuevo todos los datos: nombre del script, nombres de las variables, etcétera, con lo que, cualquier usuario y desde cualquier sitio, puede acceder a ese script.

No haría falta ni usar nuestro formulario. Bastaría guardar una copia del mismo en el ordenador del visitante y después –haciendo ligerísimos retoques– se podría acceder a nuestro script sin necesidad de utilizar el formulario alojado en nuestro servidor.

Si pensamos que uno de nuestros scripts puede estar diseñado con el fin de modificar algunos de los contenidos de nuestro espacio –borrar datos, por ejemplo– seguramente sería cuestión de empezar a preocuparnos, y mucho más si en nuestro servidor tenemos datos importantes.

Existen formas de evitar, o al menos reducir, este tipo de riesgos. Restringir a usuarios autorizados el uso de algunos subdirectorios es una de ellas, almacenar datos importantes fuera del directorio root del servidor es otra y el uso de algunas de las variables predefinidas como elementos de protección puede ser una tercera.

Hacemos este comentario a título meramente informativo. Por el momento nos basta con manejar los formularios, pero queremos que tengas presente la existencia de ese tipo de riesgos. Más adelante, ve- remos la manera de tratar de evitarlos. En los contenidos opcionales de estos materiales hemos incluido información relativa a la configuración y uso de servidores seguros que pueden paliar en gran medida algunos de estos riesgos de seguridad.