From 3250fbb2419e9b31a4bcef96fd1a1b633569b421 Mon Sep 17 00:00:00 2001 From: Luis Gil Date: Sat, 1 Apr 2017 17:29:47 +0000 Subject: [PATCH] updating all the documents from trunk to 2.4 branch to be up to date version 2.4 git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.4.x@1789828 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/howto/access.html | 4 + docs/manual/howto/access.html.es | 236 ++++++++ docs/manual/howto/access.xml.es | 214 ++++++++ docs/manual/howto/access.xml.meta | 1 + docs/manual/howto/auth.html | 4 + docs/manual/howto/auth.html.es | 713 +++++++++++++++++++++++++ docs/manual/howto/auth.xml.es | 682 +++++++++++++++++++++++ docs/manual/howto/auth.xml.meta | 1 + docs/manual/howto/cgi.html | 4 + docs/manual/howto/cgi.html.es | 615 +++++++++++++++++++++ docs/manual/howto/cgi.xml.es | 594 ++++++++++++++++++++ docs/manual/howto/cgi.xml.meta | 1 + docs/manual/howto/htaccess.html | 4 + docs/manual/howto/htaccess.html.es | 464 ++++++++++++++++ docs/manual/howto/htaccess.xml.es | 475 ++++++++++++++++ docs/manual/howto/htaccess.xml.meta | 1 + docs/manual/howto/http2.html.es | 283 ++++++++++ docs/manual/howto/http2.xml.es | 258 +++++++++ docs/manual/howto/http2.xml.meta | 1 + docs/manual/howto/index.html | 4 + docs/manual/howto/index.xml.es | 145 +++++ docs/manual/howto/index.xml.meta | 1 + docs/manual/howto/public_html.html | 4 + docs/manual/howto/public_html.xml.es | 198 +++++++ docs/manual/howto/public_html.xml.meta | 1 + 25 files changed, 4908 insertions(+) create mode 100644 docs/manual/howto/access.html.es create mode 100644 docs/manual/howto/access.xml.es create mode 100644 docs/manual/howto/auth.html.es create mode 100644 docs/manual/howto/auth.xml.es create mode 100644 docs/manual/howto/cgi.html.es create mode 100644 docs/manual/howto/cgi.xml.es create mode 100644 docs/manual/howto/htaccess.html.es create mode 100644 docs/manual/howto/htaccess.xml.es create mode 100644 docs/manual/howto/http2.html.es create mode 100644 docs/manual/howto/http2.xml.es create mode 100644 docs/manual/howto/index.xml.es create mode 100644 docs/manual/howto/public_html.xml.es diff --git a/docs/manual/howto/access.html b/docs/manual/howto/access.html index 0ce25e0e0a..77bb4ed162 100644 --- a/docs/manual/howto/access.html +++ b/docs/manual/howto/access.html @@ -4,6 +4,10 @@ URI: access.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: access.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + URI: access.html.fr Content-Language: fr Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/howto/access.html.es b/docs/manual/howto/access.html.es new file mode 100644 index 0000000000..54158e1a97 --- /dev/null +++ b/docs/manual/howto/access.html.es @@ -0,0 +1,236 @@ + + + + + +Control de Acceso - Servidor Apache HTTP Versión 2.4 + + + + + + + +

+Apache > Servidor HTTP > Documentación > Versión 2.4 > How-To / Tutoriales

Control de Acceso

Idiomas disponibles: en | + es | + fr

+ +

El control de acceso, hace referencia a todos los medios que proporcionan + una forma de controlar el acceso a cualquier recurso. Esta parte está + separada de autenticación y autorización.

Módulos y Directivas relacionados
Control de Acceso por host
Control de acceso por variables arbitrarias.
Control de acceso con mod_rewrite
Más información

Consulte también

Comentarios

Módulos y Directivas relacionados

+ +

El control de acceso puede efectuarse mediante diferentes módulos. Los + más importantes de éstos son mod_authz_core y + mod_authz_host. También se habla en este documento de + el control de acceso usando el módulo mod_rewrite.

+ +

Control de Acceso por host

+ Si lo que se quiere es restringir algunas zonas del sitio web, basándonos + en la dirección del visitante, esto puede ser realizado de manera + fácil con el módulo mod_authz_host. +

+ +

La directiva Require + proporciona una variedad de diferentes maneras de permitir o denegar el acceso a los recursos. Además puede ser usada junto con las directivas:RequireAll, RequireAny, y RequireNone, estos requerimientos pueden + ser combinados de forma compleja y arbitraria, para cumplir cualquiera que + sean tus políticas de acceso.

+ +

+ Las directivas Allow, + Deny, y + Order, + proporcionadas por mod_access_compat, están obsoletas y + serán quitadas en futuras versiones. Deberá evitar su uso, y también + los tutoriales desactualizaos que recomienden su uso. +

+ +

El uso de estas directivas es:

+ + +

Require host address 

+Require ip ip.address
+

+ + +

En la primera línea, address es el FQDN de un nombre de + dominio (o un nombre parcial del dominio); puede proporcionar múltiples + direcciones o nombres de dominio, si se desea. +

+ +

En la segunda línea, ip.address es la dirección IP, una + dirección IP parcial, una red con su máscara, o una especificación red/nnn + CIDR. Pueden usarse tanto IPV4 como IPV6.

+ +

Consulte también la + documentación de mod_authz_host para otros ejemplos de esta sintaxis. +

+ +

Puede ser insertado not para negar un requisito en particular. + Note que, ya que not es una negación de un valor, no puede ser + usado por si solo para permitir o denegar una petición, como not true + que no contituye ser false. En consecuencia, para denegar una + visita usando una negación, el bloque debe tener un elemento que se evalúa como + verdadero o falso. Por ejemplo, si tienes a alguien espameandote tu tablón de + mensajes, y tu quieres evitar que entren o dejarlos fuera, puedes realizar + lo siguiente: +

+ +

<RequireAll>
+    Require all granted
+    Require not ip 10.252.46.165
+</RequireAll>

+ + +

Los visitantes que vengan desde la IP que se configura (10.252.46.165) + no tendrán acceso al contenido que cubre esta directiva. Si en cambio, lo que se + tiene es el nombre de la máquina, en vez de la IP, podrás usar:

+ +

Require not host host.example.com
+

+ + +

Y, Si lo que se quiere es bloquear el acceso desde dominio especifico, + podrás especificar parte de una dirección o nombre de dominio:

+ +

Require not ip 192.168.205
+Require not host phishers.example.com moreidiots.example
+Require not host gov

+ + +

Uso de las directivas RequireAll, RequireAny, y RequireNone pueden ser usadas + para forzar requisitos más complejos.

+ +

Control de acceso por variables arbitrarias.

+ +

Haciendo el uso de <If>, + puedes permitir o denegar el acceso basado en variables de entrono arbitrarias + o en los valores de las cabeceras de las peticiones. Por ejemplo para denegar + el acceso basándonos en el "user-agent" (tipo de navegador así como Sistema Operativo) + puede que hagamos lo siguiente: +

+ +

<If "%{HTTP_USER_AGENT} == 'BadBot'">
+    Require all denied
+</If>

+ + +

Usando la sintaxis de Require + expr , esto también puede ser escrito de la siguiente forma: +

+ + +

Require expr %{HTTP_USER_AGENT} != 'BadBot'

+ + +

Advertencia:

El control de acceso por User-Agent es una técnica poco fiable, + ya que la cabecera de User-Agent puede ser modificada y establecerse + al antojo del usuario.

+ +

Vea también la página de expresiones + para una mayor aclaración de que sintaxis tienen las expresiones y que + variables están disponibles.

+ +

Control de acceso con mod_rewrite

+ +

El flag [F] de RewriteRule causa una respuesta 403 Forbidden + para ser enviada. USando esto, podrá denegar el acceso a recursos basándose + en criterio arbitrario.

+ +

Por ejemplo, si lo que desea es bloquear un recurso entre las 8pm y las + 7am, podrá hacerlo usando mod_rewrite:

+ +

RewriteEngine On
+RewriteCond "%{TIME_HOUR}" ">=20" [OR]
+RewriteCond "%{TIME_HOUR}" "<07"
+RewriteRule "^/fridge"     "-"       [F]

+ + +

Esto devolverá una respuesta de error 403 Forbidden para cualquier petición + después de las 8pm y antes de las 7am. Esta técnica puede ser usada para cualquier + criterio que desee usar. También puede redireccionar, o incluso reescribir estas + peticiones, si se prefiere ese enfoque. +

+ +

La directiva <If>, + añadida en la 2.4, sustituye muchas cosas que mod_rewrite + tradicionalmente solía hacer, y deberá comprobar estas antes de recurrir a +

+ +

Más información

+ +

El motor de expresiones le da una gran + capacidad de poder para hacer una gran variedad de cosas basadas en + las variables arbitrarias del servidor, y debe consultar este + documento para más detalles.

+ +

También, deberá leer la documentación de mod_authz_core + para ejemplos de combinaciones de múltiples requisitos de acceso y especificar + cómo interactúan. +

+ +

Vea también los howtos de Authenticación y Autorización +

Idiomas disponibles: en | + es | + fr

Comentarios

Notice:
This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.

+ \ No newline at end of file diff --git a/docs/manual/howto/access.xml.es b/docs/manual/howto/access.xml.es new file mode 100644 index 0000000000..096145f34a --- /dev/null +++ b/docs/manual/howto/access.xml.es @@ -0,0 +1,214 @@ + + + + + + + + + +How-To / Tutoriales + +Control de Acceso + +

El control de acceso, hace referencia a todos los medios que proporcionan + una forma de controlar el acceso a cualquier recurso. Esta parte estÃ¡ + separada de autenticaciÃ³n y autorizaciÃ³n.

+ + + +

Control de Acceso por host +

+ Si lo que se quiere es restringir algunas zonas del sitio web, basÃ¡ndonos + en la direcciÃ³n del visitante, esto puede ser realizado de manera + fÃ¡cil con el mÃ³dulo mod_authz_host. +

+ +

La directiva Require + proporciona una variedad de diferentes maneras de permitir o denegar el acceso a los recursos. AdemÃ¡s puede ser usada junto con las directivas:RequireAll, RequireAny, y RequireNone, estos requerimientos pueden + ser combinados de forma compleja y arbitraria, para cumplir cualquiera que + sean tus polÃticas de acceso.

+ +

+ Las directivas Allow, + Deny, y + Order, + proporcionadas por mod_access_compat, estÃ¡n obsoletas y + serÃ¡n quitadas en futuras versiones. DeberÃ¡ evitar su uso, y tambiÃ©n + los tutoriales desactualizaos que recomienden su uso. +

+ +

El uso de estas directivas es:

+ + + +Require host address
+Require ip ip.address + + +

En la primera lÃnea, address es el FQDN de un nombre de + dominio (o un nombre parcial del dominio); puede proporcionar mÃºltiples + direcciones o nombres de dominio, si se desea. +

+ +

En la segunda lÃnea, ip.address es la direcciÃ³n IP, una + direcciÃ³n IP parcial, una red con su mÃ¡scara, o una especificaciÃ³n red/nnn + CIDR. Pueden usarse tanto IPV4 como IPV6.

+ +

Consulte tambiÃ©n la + documentaciÃ³n de mod_authz_host para otros ejemplos de esta sintaxis. +

+ +

Puede ser insertado not para negar un requisito en particular. + Note que, ya que not es una negaciÃ³n de un valor, no puede ser + usado por si solo para permitir o denegar una peticiÃ³n, como not true + que no contituye ser false. En consecuencia, para denegar una + visita usando una negaciÃ³n, el bloque debe tener un elemento que se evalÃºa como + verdadero o falso. Por ejemplo, si tienes a alguien espameandote tu tablÃ³n de + mensajes, y tu quieres evitar que entren o dejarlos fuera, puedes realizar + lo siguiente: +

+ + +<RequireAll> + Require all granted + Require not ip 10.252.46.165 +</RequireAll> + + +

Los visitantes que vengan desde la IP que se configura (10.252.46.165) + no tendrÃ¡n acceso al contenido que cubre esta directiva. Si en cambio, lo que se + tiene es el nombre de la mÃ¡quina, en vez de la IP, podrÃ¡s usar:

+ + +Require not host host.example.com + + +

Y, Si lo que se quiere es bloquear el acceso desde dominio especifico, + podrÃ¡s especificar parte de una direcciÃ³n o nombre de dominio:

+ + +Require not ip 192.168.205 +Require not host phishers.example.com moreidiots.example +Require not host gov + + +

Uso de las directivas RequireAll, RequireAny, y RequireNone pueden ser usadas + para forzar requisitos mÃ¡s complejos.

+ +

Control de acceso por variables arbitrarias. + +

Haciendo el uso de If, + puedes permitir o denegar el acceso basado en variables de entrono arbitrarias + o en los valores de las cabeceras de las peticiones. Por ejemplo para denegar + el acceso basÃ¡ndonos en el "user-agent" (tipo de navegador asÃ como Sistema Operativo) + puede que hagamos lo siguiente: +

+ + +<If "%{HTTP_USER_AGENT} == 'BadBot'"> + Require all denied +</If> + + +

Usando la sintaxis de Require + expr , esto tambiÃ©n puede ser escrito de la siguiente forma: +

+ + + +Require expr %{HTTP_USER_AGENT} != 'BadBot' + + + Advertencia: +

El control de acceso por User-Agent es una tÃ©cnica poco fiable, + ya que la cabecera de User-Agent puede ser modificada y establecerse + al antojo del usuario.

+ + +

Vea tambiÃ©n la pÃ¡gina de expresiones + para una mayor aclaraciÃ³n de que sintaxis tienen las expresiones y que + variables estÃ¡n disponibles.

+ +

Control de acceso con mod_rewrite + +

El flag [F] de RewriteRule causa una respuesta 403 Forbidden + para ser enviada. USando esto, podrÃ¡ denegar el acceso a recursos basÃ¡ndose + en criterio arbitrario.

+ +

Por ejemplo, si lo que desea es bloquear un recurso entre las 8pm y las + 7am, podrÃ¡ hacerlo usando mod_rewrite:

+ + +RewriteEngine On +RewriteCond "%{TIME_HOUR}" ">=20" [OR] +RewriteCond "%{TIME_HOUR}" "<07" +RewriteRule "^/fridge" "-" [F] + + +

Esto devolverÃ¡ una respuesta de error 403 Forbidden para cualquier peticiÃ³n + despuÃ©s de las 8pm y antes de las 7am. Esta tÃ©cnica puede ser usada para cualquier + criterio que desee usar. TambiÃ©n puede redireccionar, o incluso reescribir estas + peticiones, si se prefiere ese enfoque. +

+ +

La directiva If, + aÃ±adida en la 2.4, sustituye muchas cosas que mod_rewrite + tradicionalmente solÃa hacer, y deberÃ¡ comprobar estas antes de recurrir a +

+ +

MÃ¡s informaciÃ³n + +

+ +

TambiÃ©n, deberÃ¡ leer la documentaciÃ³n de mod_authz_core + para ejemplos de combinaciones de mÃºltiples requisitos de acceso y especificar + cÃ³mo interactÃºan. +

+ +

Vea tambiÃ©n los howtos de AuthenticaciÃ³n y AutorizaciÃ³n +

+ + diff --git a/docs/manual/howto/access.xml.meta b/docs/manual/howto/access.xml.meta index 605822ecb4..95d284ca3a 100644 --- a/docs/manual/howto/access.xml.meta +++ b/docs/manual/howto/access.xml.meta @@ -8,6 +8,7 @@ en + es fr diff --git a/docs/manual/howto/auth.html b/docs/manual/howto/auth.html index a8c8b7e37d..c62314a8bf 100644 --- a/docs/manual/howto/auth.html +++ b/docs/manual/howto/auth.html @@ -4,6 +4,10 @@ URI: auth.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: auth.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + URI: auth.html.fr Content-Language: fr Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/howto/auth.html.es b/docs/manual/howto/auth.html.es new file mode 100644 index 0000000000..4589cc1f93 --- /dev/null +++ b/docs/manual/howto/auth.html.es @@ -0,0 +1,713 @@ + + + + + +Autenticación y Autorización - Servidor Apache HTTP Versión 2.4 + + + + + + + +

+Apache > Servidor HTTP > Documentación > Versión 2.4 > How-To / Tutoriales

Autenticación y Autorización

Idiomas disponibles: en | + es | + fr | + ja | + ko | + tr

+ +

Autenticación es cualquier proceso por el cuál se verifica que uno es + quien dice ser. Autorización es cualquier proceso en el cuál cualquiera + está permitido a estar donde se quiera, o tener información la cuál se + quiera tener. +

+ +

Para información de control de acceso de forma genérica visiteHow to de Control de Acceso.

Módulos y Directivas Relacionados
Introducción
Los Prerequisitos
Conseguir que funcione
Dejar que más de una persona + entre
Posibles Problemas
Método alternativo de almacenamiento de las + contraseñas
Uso de múltiples proveedores
Más allá de la Autorización
Cache de Autenticación
Más información

Consulte también

Comentarios

Módulos y Directivas Relacionados

+ +

Hay tres tipos de módulos involucrados en los procesos de la autenticación + y autorización. Normalmente deberás escoger al menos un módulo de cada grupo.

+ +

Modos de Autenticación (consulte la directiva + AuthType ) +
- mod_auth_basic
- mod_auth_digest
+
Proveedor de Autenticación (consulte la directiva + AuthBasicProvider y + AuthDigestProvider) + +
- mod_authn_anon
- mod_authn_dbd
- mod_authn_dbm
- mod_authn_file
- mod_authnz_ldap
- mod_authn_socache
+
Autorización (consulte la directiva + Require) +
- mod_authnz_ldap
- mod_authz_dbd
- mod_authz_dbm
- mod_authz_groupfile
- mod_authz_host
- mod_authz_owner
- mod_authz_user
+

+ +

A parte de éstos módulos, también están + mod_authn_core y + mod_authz_core. Éstos módulos implementan las directivas + esenciales que son el centro de todos los módulos de autenticación.

+ +

El módulo mod_authnz_ldap es tanto un proveedor de + autenticación como de autorización. El módulo + mod_authz_host proporciona autorización y control de acceso + basado en el nombre del Host, la dirección IP o características de la propia + petición, pero no es parte del sistema proveedor de + autenticación. Para tener compatibilidad inversa con el mod_access, + hay un nuevo modulo llamado mod_access_compat.

+ +

También puedes mirar el how-to de Control de Acceso , donde se plantean varias formas del control de acceso al servidor.

+ +

Introducción

Si se tiene información en nuestra página web que sea información + sensible o pensada para un grupo reducido de usuarios/personas, + las técnicas que se describen en este manual, le servirán + de ayuda para asegurarse de que las personas que ven esas páginas sean + las personas que uno quiere.

+ +

Este artículo cubre la parte "estándar" de cómo proteger partes de un + sitio web que muchos usarán.

+ +

Nota:

Si de verdad es necesario que tus datos estén en un sitio seguro, + considera usar mod_ssl como método de autenticación adicional a cualquier forma de autenticación.

Los Prerequisitos

Las directivas que se usan en este artículo necesitaran ponerse ya sea + en el fichero de configuración principal del servidor ( típicamente en + la sección + <Directory> de httpd.conf ), o + en cada uno de los ficheros de configuraciones del propio directorio + (los archivos .htaccess).

+ +

Si planea usar los ficheros .htaccess , necesitarás + tener en la configuración global del servidor, una configuración que permita + poner directivas de autenticación en estos ficheros. Esto se hace con la + directiva AllowOverride, la cual especifica + que directivas, en su caso, pueden ser puestas en cada fichero de configuración + por directorio.

+ +

Ya que estamos hablando aquí de autenticación, necesitarás una directiva + AllowOverride como la siguiente: +

+ +

AllowOverride AuthConfig

+ + +

O, si solo se van a poner las directivas directamente en la configuración + principal del servidor, deberás tener, claro está, permisos de escritura + en el archivo.

+ +

Y necesitarás saber un poco de como está estructurado el árbol de + directorios de tu servidor, para poder saber donde se encuentran algunos + archivos. Esto no debería ser una tarea difícil, aún así intentaremos + dejarlo claro llegado el momento de comentar dicho aspecto.

+ +

También deberás de asegurarte de que los módulos + mod_authn_core y mod_authz_core + han sido incorporados, o añadidos a la hora de compilar en tu binario httpd o + cargados mediante el archivo de configuración httpd.conf. Estos + dos módulos proporcionan directivas básicas y funcionalidades que son críticas + para la configuración y uso de autenticación y autorización en el servidor web.

Conseguir que funcione

Aquí está lo básico de cómo proteger con contraseña un directorio en tu + servidor.

+ +

Primero, necesitarás crear un fichero de contraseña. Dependiendo de que + proveedor de autenticación se haya elegido, se hará de una forma u otra. Para empezar, + usaremos un fichero de contraseña de tipo texto.

+ +

Este fichero deberá estar en un sitio que no se pueda tener acceso desde + la web. Esto también implica que nadie pueda descargarse el fichero de + contraseñas. Por ejemplo, si tus documentos están guardados fuera de + /usr/local/apache/htdocs, querrás poner tu archivo de contraseñas en + /usr/local/apache/passwd.

+ +

Para crear el fichero de contraseñas, usa la utilidad + htpasswd que viene con Apache. Esta herramienta se + encuentra en el directorio /bin en donde sea que se ha + instalado el Apache. Si ha instalado Apache desde un paquete de terceros, + puede ser que se encuentre en su ruta de ejecución.

+ +

Para crear el fichero, escribiremos:

+ +

+ htpasswd -c /usr/local/apache/passwd/passwords rbowen +

+ +

htpasswd te preguntará por una contraseña, y después + te pedirá que la vuelvas a escribir para confirmarla:

+ +

+ $ htpasswd -c /usr/local/apache/passwd/passwords rbowen + New password: mypassword + Re-type new password: mypassword + Adding password for user rbowen +

+ +

Si htpasswd no está en tu variable de entorno "path" del + sistema, por supuesto deberás escribir la ruta absoluta del ejecutable para + poder hacer que se ejecute. En una instalación por defecto, está en: + /usr/local/apache2/bin/htpasswd

+ +

Lo próximo que necesitas, será configurar el servidor para que pida una + contraseña y así decirle al servidor que usuarios están autorizados a acceder. + Puedes hacer esto ya sea editando el fichero httpd.conf + de configuración o usando in fichero .htaccess. Por ejemplo, + si quieres proteger el directorio + /usr/local/apache/htdocs/secret, puedes usar las siguientes + directivas, ya sea en el fichero .htaccess localizado en + following directives, either placed in the file + /usr/local/apache/htdocs/secret/.htaccess, o + en la configuración global del servidor httpd.conf dentro de la + sección <Directory + "/usr/local/apache/htdocs/secret"> , como se muestra a continuación:

+ +

<Directory "/usr/local/apache/htdocs/secret">
+AuthType Basic
+AuthName "Restricted Files"
+# (Following line optional)
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+Require user rbowen
+</Directory>

+ + +

Vamos a explicar cada una de las directivas individualmente. + La directiva AuthType selecciona el método + que se usa para autenticar al usuario. El método más común es + Basic, y éste es el método que implementa + mod_auth_basic. Es muy importante ser consciente, + de que la autenticación básica, envía las contraseñas desde el cliente + al servidor sin cifrar. + Este método por tanto, no debe ser utilizado para proteger datos muy sensibles, + a no ser que, este método de autenticación básica, sea acompañado del módulo + mod_ssl. + Apache soporta otro método más de autenticación que es del tipo + AuthType Digest. Este método, es implementado por el módulo mod_auth_digest y con el se pretendía crear una autenticación más + segura. Este ya no es el caso, ya que la conexión deberá realizarse con mod_ssl en su lugar. +

+ +

La directiva AuthName + establece el Realm para ser usado en la autenticación. El + Realm tiene dos funciones principales. + La primera, el cliente presenta a menudo esta información al usuario como + parte del cuadro de diálogo de contraseña. La segunda, que es utilizado por + el cliente para determinar qué contraseña enviar a para una determinada zona + de autenticación.

+ +

Así que, por ejemple, una vez que el cliente se ha autenticado en el área de + los "Ficheros Restringidos", entonces re-intentará automáticamente + la misma contraseña para cualquier área en el mismo servidor que es marcado + con el Realm de "Ficheros Restringidos" + Por lo tanto, puedes prevenir que a un usuario se le pida mas de una vez por su + contraseña, compartiendo así varias áreas restringidas el mismo Realm + Por supuesto, por razones de seguridad, el cliente pedirá siempre por una contraseña, + siempre y cuando el nombre del servidor cambie. +

+ +

La directiva AuthBasicProvider es, + en este caso, opcional, ya que file es el valor por defecto + para esta directiva. Deberás usar esta directiva si estas usando otro medio + diferente para la autenticación, como por ejemplo + mod_authn_dbm o mod_authn_dbd.

+ +

La directiva AuthUserFile + establece el path al fichero de contraseñas que acabamos de crear con el + comando htpasswd. Si tiene un número muy grande de usuarios, + puede ser realmente lento el buscar el usuario en ese fichero de texto plano + para autenticar a los usuarios en cada petición. + Apache también tiene la habilidad de almacenar información de usuarios en + unos ficheros de rápido acceso a modo de base de datos. + El módulo mod_authn_dbm proporciona la directiva AuthDBMUserFile. Estos ficheros pueden ser creados y + manipulados con el programa dbmmanage y htdbm. + Muchos otros métodos de autenticación así como otras opciones, están disponibles en + módulos de terceros + Base de datos de Módulos disponibles.

+ +

Finalmente, la directiva Require + proporciona la parte del proceso de autorización estableciendo el o los + usuarios que se les está permitido acceder a una región del servidor. + En la próxima sección, discutiremos las diferentes vías de utilizar la + directiva Require.

Dejar que más de una persona + entre

Las directivas mencionadas arriba sólo permiten a una persona + (especialmente con un usuario que en ej ejemplo es rbowen) + en el directorio. En la mayoría de los casos, se querrá permitir el acceso + a más de una persona. Aquí es donde la directiva + AuthGroupFile entra en juego.

+ +

Si lo que se desea es permitir a más de una persona el acceso, necesitarás + crear un archivo de grupo que asocie los nombres de grupos con el de personas + para permitirles el acceso. El formato de este fichero es bastante sencillo, + y puedes crearlo con tu editor de texto favorito. El contenido del fichero + se parecerá a:

+ +

+ GroupName: rbowen dpitts sungo rshersey +

+ +

Básicamente eso es la lista de miembros los cuales están en un mismo fichero + de grupo en una sola linea separados por espacios.

+ +

Para añadir un usuario a tu fichero de contraseñas existente teclee:

+ +

+ htpasswd /usr/local/apache/passwd/passwords dpitts +

+ +

Te responderá lo mismo que anteriormente, pero se añadirá al fichero + existente en vez de crear uno nuevo. (Es decir el flag -c será + el que haga que se genere un nuevo + fichero de contraseñas).

+ +

Ahora, tendrá que modificar su fichero .htaccess para que sea + parecido a lo siguiente:

+ +

AuthType Basic
+AuthName "By Invitation Only"
+# Optional line:
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthGroupFile "/usr/local/apache/passwd/groups"
+Require group GroupName

+ + +

Ahora, cualquiera que esté listado en el grupo GroupName, + y tiene una entrada en el fichero de contraseñas, se les + permitirá el acceso, si introducen su contraseña correctamente.

+ +

Hay otra manera de dejar entrar a varios usuarios, que es menos específica. + En lugar de crear un archivo de grupo, sólo puede utilizar la siguiente + directiva:

+ +

Require valid-user

+ + +

Usando ésto en vez de la línea Require user rbowen + permitirá a cualquier persona acceder, la cuál aparece en el archivo de + contraseñas, y que introduzca correctamente su contraseña. Incluso puede + emular el comportamiento del grupo aquí, sólo manteniendo un fichero de + contraseñas independiente para cada grupo. La ventaja de este enfoque es + que Apache sólo tiene que comprobar un archivo, en lugar de dos. La desventaja + es que se tiene que mantener un montón de ficheros de contraseña de grupo, y + recuerde hacer referencia al fichero correcto en la directiva + AuthUserFile.

Posibles Problemas

Debido a la forma en que se especifica la autenticación básica, + su nombre de usuario y la contraseña deben ser verificados cada vez + que se solicita un documento desde el servidor. Esto es, incluso si + se vuelve a cargar la misma página, y para cada imagen de la página (si + provienen de un directorio protegido). Como se puede imaginar, esto + ralentiza las cosas un poco. La cantidad que ralentiza las cosas es + proporcional al tamaño del archivo de contraseñas, porque tiene que + abrir ese archivo, recorrer lista de usuarios hasta que llega a su nombre. + Y tiene que hacer esto cada vez que se carga una página.

+ +

Una consecuencia de esto, es que hay un limite práctico de cuantos + usuarios puedes introducir en el fichero de contraseñas. Este límite + variará dependiendo de la máquina en la que tengas el servidor, + pero puedes notar ralentizaciones en cuanto se metan cientos de entradas, + y por lo tanto consideraremos entonces otro método de autenticación + en ese momento. +

Método alternativo de almacenamiento de las + contraseñas

+ +

Debido a que el almacenamiento de las contraseñas en texto plano tiene + el problema mencionado anteriormente, puede que se prefiera guardar + las contraseñas en otro lugar como por ejemplo una base de datos. +

+ +

Los módulos mod_authn_dbm y mod_authn_dbd son + dos módulos que hacen esto posible. En vez de seleccionar la directiva de fichero + AuthBasicProvider , en su lugar + se puede elegir dbm o dbd como formato de almacenamiento.

+ +

Para seleccionar los ficheros de tipo dbm en vez de texto plano, podremos hacer algo parecido a lo siguiente:

+ +

<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider dbm
+    AuthDBMUserFile "/www/passwords/passwd.dbm"
+    Require valid-user
+</Directory>

+ + +

Hay otras opciones disponibles. Consulta la documentación de + mod_authn_dbm para más detalles.

Uso de múltiples proveedores

+ +

Con la introducción de la nueva autenticación basada en un proveedor y + una arquitectura de autorización, ya no estaremos restringidos a un único + método de autenticación o autorización. De hecho, cualquier número de + los proveedores pueden ser mezclados y emparejados para ofrecerle + exactamente el esquema que se adapte a sus necesidades. + En el siguiente ejemplo, veremos como ambos proveedores tanto el fichero + como el LDAP son usados en la autenticación: +

+ +

<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file ldap
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    Require valid-user
+</Directory>

+ + +

En este ejemplo el fichero, que actúa como proveedor, intentará autenticar + primero al usuario. Si no puede autenticar al usuario, el proveedor del LDAP + será llamado para que realice la autenticación. + Esto permite al ámbito de autenticación ser amplio, si su organización + implementa más de un tipo de almacén de autenticación. + Otros escenarios de autenticación y autorización pueden incluir la + mezcla de un tipo de autenticación con un tipo diferente de autorización. + Por ejemplo, autenticar contra un fichero de contraseñas pero autorizando + dicho acceso mediante el directorio del LDAP.

+ +

Así como múltiples métodos y proveedores de autenticación pueden + ser implementados, también pueden usarse múltiples formas de + autorización. + En este ejemplo ambos ficheros de autorización de grupo así como + autorización de grupo mediante LDAP va a ser usado: +

+ +

<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    AuthGroupFile "/usr/local/apache/passwd/groups"
+    Require group GroupName
+    Require ldap-group cn=mygroup,o=yourorg
+</Directory>

+ + +

Para llevar la autorización un poco más lejos, las directivas + de autorización de contenedores tales como + <RequireAll> + and + <RequireAny> + nos permiten aplicar una lógica de en qué orden se manejará la autorización dependiendo + de la configuración y controlada a través de ella. + Mire también Contenedores de + Autorización para ejemplos de cómo pueden ser aplicados.

+ +

Más allá de la Autorización

+ +

El modo en que la autorización puede ser aplicada es ahora mucho más flexible + que us solo chequeo contra un almacén de datos (contraseñas). Ordenando la + lógica y escoger la forma en que la autorización es realizada, ahora es posible +

+ +

Aplicando la lógica y ordenación

Controlar el cómo y en qué orden se va a aplicar la autorización ha + sido un misterio en el pasado. En Apache 2.2 un proveedor del + mecanismo de autenticación fue introducido para disociar el proceso actual + de autenticación y soportar funcionalidad. + Uno de los beneficios secundarios fue que los proveedores de autenticación + podían ser configurados y llamados en un orden especifico que no dependieran + en el orden de carga del propio modulo. + Este proveedor de dicho mecanismo, ha sido introducido en la autorización + también. Lo que esto significa es que la directiva + Require + no sólo especifica que método de autorización deberá ser usado, si no + también especifica el orden en que van a ser llamados. Múltiples + métodos de autorización son llamados en el mismo orden en que la directiva + Require aparece en la + configuración. +

+ +

+ Con la Introducción del contenedor de directivas de autorización tales como + <RequireAll> + y + <RequireAny>, + La configuración también tiene control sobre cuándo se llaman a los métodos + de autorización y qué criterios determinan cuándo se concede el acceso. + Vease + Contenedores de autorización + Para un ejemplo de cómo pueden ser utilizados para expresar una lógica + más compleja de autorización. +

+ +

+ Por defecto todas las directivas + Require + son manejadas como si estuvieran contenidas en una directiva + <RequireAny>. + En otras palabras, Si alguno de los métodos de autorización + especificados tiene éxito, se concede la autorización. +

+ + + +

Uso de los proveedores de autorización para + el control de acceso

+ +

+ La autenticación de nombre de usuario y contraseña es sólo parte + de toda la historia que conlleva el proceso. Frecuentemente quiere + dar acceso a la gente en base a algo más que lo que son. + Algo como de donde vienen. +

+ +

+ Los proveedores de autorización all, + env, host y ip + te permiten denegar o permitir el acceso basándose en otros + criterios como el nombre de la máquina o la IP de la máquina que + realiza la consulta para un documento. +

+ +

+ El uso de estos proveedores se especifica a través de la directiva + Require. + La directiva registra los proveedores de autorización que serán llamados + durante la solicitud de la fase del proceso de autorización. Por ejemplo: +

+ +

Require ip address
+

+ + +

+ Donde address es una dirección IP (o una dirección IP parcial) + o bien: +

+ +

Require host domain_name
+

+ + +

+ Donde domain_name es el nombre completamente cualificado de un nombre + de dominio (FQDN) (o un nombre parcial del dominio); + puede proporcionar múltiples direcciones o nombres de dominio, si se desea. +

+ +

+ Por ejemplo, si alguien envía spam a su tablón de mensajes y desea + mantenerlos alejados, podría hacer lo siguiente:

+ +

<RequireAll>
+    Require all granted
+    Require not ip 10.252.46.165
+</RequireAll>

+ + +

+ Visitantes que vengan desde esa IP no serán capaces de ver el contenido + que cubre esta directiva. Si, en cambio, lo que se tiene es el nombre de + la máquina, en vez de la dirección IP, podría usar: +

+ +

<RequireAll>
+    Require all granted
+    Require not host host.example.com
+</RequireAll>

+ + +

+ Y, si lo que se quiere es bloquear el acceso desde un determinado dominio + (bloquear el acceso desde el dominio entero), puede especificar parte + de la dirección o del propio dominio a bloquear: +

+ +

<RequireAll>
+    Require all granted
+    Require not ip 192.168.205
+    Require not host phishers.example.com moreidiots.example
+    Require not host ke
+</RequireAll>

+ + +

+ Usando <RequireAll> + con múltiples directivas <Require>, cada una negada con un not, + Sólo permitirá el acceso, si todas las condiciones negadas son verdaderas. + En otras palabras, el acceso será bloqueado, si cualquiera de las condiciones + negadas fallara. +

+ + + +

Compatibilidad de Control de Acceso con versiones + anteriores

+ +

+ Uno de los efectos secundarios de adoptar proveedores basados en + mecanismos de autenticación es que las directivas anteriores + Order, + Allow, + Deny y + Satisfy ya no son necesarias. + Sin embargo, para proporcionar compatibilidad con configuraciones antiguas, + estas directivas se han movido al módulo mod_access_compat. +

+ +

Nota:

+ Las directivas proporcionadas por mod_access_compat + han quedado obsoletas por mod_authz_host. Mezclar + directivas antiguas como + Order, + Allow ó + Deny con las nuevas + como + Require + es técnicamente posible pero desaconsejable. El módulo + mod_access_compat se creó para soportar configuraciones + que contuvieran sólo directivas antiguas para facilitar la actualización + a la versión 2.4. + Por favor revise la documentación de + actualización para más información al + respecto. +

+ + +

Cache de Autenticación

+ Puede haber momentos en que la autenticación ponga una carga + inaceptable en el proveedor (de autenticación) o en tu red. + Esto suele afectar a los usuarios de mod_authn_dbd + (u otros proveedores de terceros/personalizados). + Para lidiar con este problema, HTTPD 2.3/2.4 introduce un nuevo proveedor + de caché mod_authn_socache para cachear las credenciales + y reducir la carga en el proveedor(es) original. +

+ Esto puede ofrecer un aumento de rendimiento sustancial para algunos usuarios. +

Más información

+ +

+ También debería leer la documentación para + mod_auth_basic y mod_authz_host + la cuál contiene más información de como funciona todo esto. + La directiva <AuthnProviderAlias> puede también ayudar + a la hora de simplificar ciertas configuraciones de autenticación. +

+ +

+ Los diferentes algoritmos de cifrado que están soportados por Apache + para la autenticación se explican en + Cifrado de Contraseñas. +

+ +

+ Y tal vez quiera ojear la documentación de "how to" + Control de Acceso donde se mencionan temas + relacionados.

+ +

Idiomas disponibles: en | + es | + fr | + ja | + ko | + tr

Comentarios

+ \ No newline at end of file diff --git a/docs/manual/howto/auth.xml.es b/docs/manual/howto/auth.xml.es new file mode 100644 index 0000000000..4d6e1c93ff --- /dev/null +++ b/docs/manual/howto/auth.xml.es @@ -0,0 +1,682 @@ + + + + + + + + + +How-To / Tutoriales + +AutenticaciÃ³n y AutorizaciÃ³n + +

AutenticaciÃ³n es cualquier proceso por el cuÃ¡l se verifica que uno es + quien dice ser. AutorizaciÃ³n es cualquier proceso en el cuÃ¡l cualquiera + estÃ¡ permitido a estar donde se quiera, o tener informaciÃ³n la cuÃ¡l se + quiera tener. +

+ +

Para informaciÃ³n de control de acceso de forma genÃ©rica visiteHow to de Control de Acceso.

+ + + +

IntroducciÃ³n +

Si se tiene informaciÃ³n en nuestra pÃ¡gina web que sea informaciÃ³n + sensible o pensada para un grupo reducido de usuarios/personas, + las tÃ©cnicas que se describen en este manual, le servirÃ¡n + de ayuda para asegurarse de que las personas que ven esas pÃ¡ginas sean + las personas que uno quiere.

+ +

Este artÃculo cubre la parte "estÃ¡ndar" de cÃ³mo proteger partes de un + sitio web que muchos usarÃ¡n.

+ + Nota: +

Si de verdad es necesario que tus datos estÃ©n en un sitio seguro, + considera usar mod_ssl como mÃ©todo de autenticaciÃ³n adicional a cualquier forma de autenticaciÃ³n.

+ +

Los Prerequisitos +

Las directivas que se usan en este artÃculo necesitaran ponerse ya sea + en el fichero de configuraciÃ³n principal del servidor ( tÃpicamente en + la secciÃ³n + Directory de httpd.conf ), o + en cada uno de los ficheros de configuraciones del propio directorio + (los archivos .htaccess).

+ +

Si planea usar los ficheros .htaccess , necesitarÃ¡s + tener en la configuraciÃ³n global del servidor, una configuraciÃ³n que permita + poner directivas de autenticaciÃ³n en estos ficheros. Esto se hace con la + directiva AllowOverride, la cual especifica + que directivas, en su caso, pueden ser puestas en cada fichero de configuraciÃ³n + por directorio.

+ +

Ya que estamos hablando aquÃ de autenticaciÃ³n, necesitarÃ¡s una directiva + AllowOverride como la siguiente: +

+ + +AllowOverride AuthConfig + + +

O, si solo se van a poner las directivas directamente en la configuraciÃ³n + principal del servidor, deberÃ¡s tener, claro estÃ¡, permisos de escritura + en el archivo.

+ +

Y necesitarÃ¡s saber un poco de como estÃ¡ estructurado el Ã¡rbol de + directorios de tu servidor, para poder saber donde se encuentran algunos + archivos. Esto no deberÃa ser una tarea difÃcil, aÃºn asÃ intentaremos + dejarlo claro llegado el momento de comentar dicho aspecto.

+ +

TambiÃ©n deberÃ¡s de asegurarte de que los mÃ³dulos + mod_authn_core y mod_authz_core + han sido incorporados, o aÃ±adidos a la hora de compilar en tu binario httpd o + cargados mediante el archivo de configuraciÃ³n httpd.conf. Estos + dos mÃ³dulos proporcionan directivas bÃ¡sicas y funcionalidades que son crÃticas + para la configuraciÃ³n y uso de autenticaciÃ³n y autorizaciÃ³n en el servidor web.

+ +

Conseguir que funcione +

AquÃ estÃ¡ lo bÃ¡sico de cÃ³mo proteger con contraseÃ±a un directorio en tu + servidor.

+ +

Primero, necesitarÃ¡s crear un fichero de contraseÃ±a. Dependiendo de que + proveedor de autenticaciÃ³n se haya elegido, se harÃ¡ de una forma u otra. Para empezar, + usaremos un fichero de contraseÃ±a de tipo texto.

+ +

Este fichero deberÃ¡ estar en un sitio que no se pueda tener acceso desde + la web. Esto tambiÃ©n implica que nadie pueda descargarse el fichero de + contraseÃ±as. Por ejemplo, si tus documentos estÃ¡n guardados fuera de + /usr/local/apache/htdocs, querrÃ¡s poner tu archivo de contraseÃ±as en + /usr/local/apache/passwd.

+ +

Para crear el fichero de contraseÃ±as, usa la utilidad + htpasswd que viene con Apache. Esta herramienta se + encuentra en el directorio /bin en donde sea que se ha + instalado el Apache. Si ha instalado Apache desde un paquete de terceros, + puede ser que se encuentre en su ruta de ejecuciÃ³n.

+ +

Para crear el fichero, escribiremos:

+ + + htpasswd -c /usr/local/apache/passwd/passwords rbowen + + +

htpasswd te preguntarÃ¡ por una contraseÃ±a, y despuÃ©s + te pedirÃ¡ que la vuelvas a escribir para confirmarla:

+ + + $ htpasswd -c /usr/local/apache/passwd/passwords rbowen
+ New password: mypassword
+ Re-type new password: mypassword
+ Adding password for user rbowen + + +

Si htpasswd no estÃ¡ en tu variable de entorno "path" del + sistema, por supuesto deberÃ¡s escribir la ruta absoluta del ejecutable para + poder hacer que se ejecute. En una instalaciÃ³n por defecto, estÃ¡ en: + /usr/local/apache2/bin/htpasswd

+ +

Lo prÃ³ximo que necesitas, serÃ¡ configurar el servidor para que pida una + contraseÃ±a y asÃ decirle al servidor que usuarios estÃ¡n autorizados a acceder. + Puedes hacer esto ya sea editando el fichero httpd.conf + de configuraciÃ³n o usando in fichero .htaccess. Por ejemplo, + si quieres proteger el directorio + /usr/local/apache/htdocs/secret, puedes usar las siguientes + directivas, ya sea en el fichero .htaccess localizado en + following directives, either placed in the file + /usr/local/apache/htdocs/secret/.htaccess, o + en la configuraciÃ³n global del servidor httpd.conf dentro de la + secciÃ³n <Directory + "/usr/local/apache/htdocs/secret"> , como se muestra a continuaciÃ³n:

+ + +<Directory "/usr/local/apache/htdocs/secret"> +AuthType Basic +AuthName "Restricted Files" +# (Following line optional) +AuthBasicProvider file +AuthUserFile "/usr/local/apache/passwd/passwords" +Require user rbowen +</Directory> + + +

Vamos a explicar cada una de las directivas individualmente. + La directiva AuthType selecciona el mÃ©todo + que se usa para autenticar al usuario. El mÃ©todo mÃ¡s comÃºn es + Basic, y Ã©ste es el mÃ©todo que implementa + mod_auth_basic. Es muy importante ser consciente, + de que la autenticaciÃ³n bÃ¡sica, envÃa las contraseÃ±as desde el cliente + al servidor sin cifrar. + Este mÃ©todo por tanto, no debe ser utilizado para proteger datos muy sensibles, + a no ser que, este mÃ©todo de autenticaciÃ³n bÃ¡sica, sea acompaÃ±ado del mÃ³dulo + mod_ssl. + Apache soporta otro mÃ©todo mÃ¡s de autenticaciÃ³n que es del tipo + AuthType Digest. Este mÃ©todo, es implementado por el mÃ³dulo mod_auth_digest y con el se pretendÃa crear una autenticaciÃ³n mÃ¡s + segura. Este ya no es el caso, ya que la conexiÃ³n deberÃ¡ realizarse con mod_ssl en su lugar. +

+ +

La directiva AuthName + establece el Realm para ser usado en la autenticaciÃ³n. El + Realm tiene dos funciones principales. + La primera, el cliente presenta a menudo esta informaciÃ³n al usuario como + parte del cuadro de diÃ¡logo de contraseÃ±a. La segunda, que es utilizado por + el cliente para determinar quÃ© contraseÃ±a enviar a para una determinada zona + de autenticaciÃ³n.

+ +

AsÃ que, por ejemple, una vez que el cliente se ha autenticado en el Ã¡rea de + los "Ficheros Restringidos", entonces re-intentarÃ¡ automÃ¡ticamente + la misma contraseÃ±a para cualquier Ã¡rea en el mismo servidor que es marcado + con el Realm de "Ficheros Restringidos" + Por lo tanto, puedes prevenir que a un usuario se le pida mas de una vez por su + contraseÃ±a, compartiendo asÃ varias Ã¡reas restringidas el mismo Realm + Por supuesto, por razones de seguridad, el cliente pedirÃ¡ siempre por una contraseÃ±a, + siempre y cuando el nombre del servidor cambie. +

+ +

La directiva AuthBasicProvider es, + en este caso, opcional, ya que file es el valor por defecto + para esta directiva. DeberÃ¡s usar esta directiva si estas usando otro medio + diferente para la autenticaciÃ³n, como por ejemplo + mod_authn_dbm o mod_authn_dbd.

+ +

La directiva AuthUserFile + establece el path al fichero de contraseÃ±as que acabamos de crear con el + comando htpasswd. Si tiene un nÃºmero muy grande de usuarios, + puede ser realmente lento el buscar el usuario en ese fichero de texto plano + para autenticar a los usuarios en cada peticiÃ³n. + Apache tambiÃ©n tiene la habilidad de almacenar informaciÃ³n de usuarios en + unos ficheros de rÃ¡pido acceso a modo de base de datos. + El mÃ³dulo mod_authn_dbm proporciona la directiva AuthDBMUserFile. Estos ficheros pueden ser creados y + manipulados con el programa dbmmanage y htdbm. + Muchos otros mÃ©todos de autenticaciÃ³n asÃ como otras opciones, estÃ¡n disponibles en + mÃ³dulos de terceros + Base de datos de MÃ³dulos disponibles.

+ +

Finalmente, la directiva Require + proporciona la parte del proceso de autorizaciÃ³n estableciendo el o los + usuarios que se les estÃ¡ permitido acceder a una regiÃ³n del servidor. + En la prÃ³xima secciÃ³n, discutiremos las diferentes vÃas de utilizar la + directiva Require.

+ +

Dejar que mÃ¡s de una persona + entre +

Las directivas mencionadas arriba sÃ³lo permiten a una persona + (especialmente con un usuario que en ej ejemplo es rbowen) + en el directorio. En la mayorÃa de los casos, se querrÃ¡ permitir el acceso + a mÃ¡s de una persona. AquÃ es donde la directiva + AuthGroupFile entra en juego.

+ +

Si lo que se desea es permitir a mÃ¡s de una persona el acceso, necesitarÃ¡s + crear un archivo de grupo que asocie los nombres de grupos con el de personas + para permitirles el acceso. El formato de este fichero es bastante sencillo, + y puedes crearlo con tu editor de texto favorito. El contenido del fichero + se parecerÃ¡ a:

+ + + GroupName: rbowen dpitts sungo rshersey + + +

BÃ¡sicamente eso es la lista de miembros los cuales estÃ¡n en un mismo fichero + de grupo en una sola linea separados por espacios.

+ +

Para aÃ±adir un usuario a tu fichero de contraseÃ±as existente teclee:

+ + + htpasswd /usr/local/apache/passwd/passwords dpitts + + +

Te responderÃ¡ lo mismo que anteriormente, pero se aÃ±adirÃ¡ al fichero + existente en vez de crear uno nuevo. (Es decir el flag -c serÃ¡ + el que haga que se genere un nuevo + fichero de contraseÃ±as).

+ +

Ahora, tendrÃ¡ que modificar su fichero .htaccess para que sea + parecido a lo siguiente:

+ + +AuthType Basic +AuthName "By Invitation Only" +# Optional line: +AuthBasicProvider file +AuthUserFile "/usr/local/apache/passwd/passwords" +AuthGroupFile "/usr/local/apache/passwd/groups" +Require group GroupName + + +

Ahora, cualquiera que estÃ© listado en el grupo GroupName, + y tiene una entrada en el fichero de contraseÃ±as, se les + permitirÃ¡ el acceso, si introducen su contraseÃ±a correctamente.

+ +

Hay otra manera de dejar entrar a varios usuarios, que es menos especÃfica. + En lugar de crear un archivo de grupo, sÃ³lo puede utilizar la siguiente + directiva:

+ + +Require valid-user + + +

Usando Ã©sto en vez de la lÃnea Require user rbowen + permitirÃ¡ a cualquier persona acceder, la cuÃ¡l aparece en el archivo de + contraseÃ±as, y que introduzca correctamente su contraseÃ±a. Incluso puede + emular el comportamiento del grupo aquÃ, sÃ³lo manteniendo un fichero de + contraseÃ±as independiente para cada grupo. La ventaja de este enfoque es + que Apache sÃ³lo tiene que comprobar un archivo, en lugar de dos. La desventaja + es que se tiene que mantener un montÃ³n de ficheros de contraseÃ±a de grupo, y + recuerde hacer referencia al fichero correcto en la directiva + AuthUserFile.

+ +

Posibles Problemas +

Debido a la forma en que se especifica la autenticaciÃ³n bÃ¡sica, + su nombre de usuario y la contraseÃ±a deben ser verificados cada vez + que se solicita un documento desde el servidor. Esto es, incluso siÂ + seÂ vuelve a cargar la misma pÃ¡gina, y para cada imagen de la pÃ¡gina (si +Â Â Â Â provienen de un directorio protegido). Como se puede imaginar, esto +Â Â Â Â ralentiza las cosas un poco. La cantidad que ralentiza las cosas es + proporcional al tamaÃ±o del archivo de contraseÃ±as, porque tiene que + abrir ese archivo, recorrerÂ lista de usuarios hasta que llega a su nombre. + Y tiene que hacer esto cada vez que se carga una pÃ¡gina.

+ +

Una consecuencia de esto, es que hay un limite prÃ¡ctico de cuantos + usuarios puedes introducir en el fichero de contraseÃ±as. Este lÃmite + variarÃ¡ dependiendo de la mÃ¡quina en la que tengas el servidor, + pero puedes notar ralentizaciones en cuanto se metan cientos de entradas, + y por lo tanto consideraremos entonces otro mÃ©todo de autenticaciÃ³n + en ese momento. +

+ +

MÃ©todo alternativo de almacenamiento de las + contraseÃ±as + +

Debido a que el almacenamiento de las contraseÃ±as en texto plano tiene + el problema mencionado anteriormente, puede que se prefiera guardar + las contraseÃ±as en otro lugar como por ejemplo una base de datos. +

+ +

Los mÃ³dulos mod_authn_dbm y mod_authn_dbd son + dos mÃ³dulos que hacen esto posible. En vez de seleccionar la directiva de fichero + AuthBasicProvider , en su lugar + se puede elegir dbm o dbd como formato de almacenamiento.

+ +

Para seleccionar los ficheros de tipo dbm en vez de texto plano, podremos hacer algo parecido a lo siguiente:

+ + +<Directory "/www/docs/private"> + AuthName "Private" + AuthType Basic + AuthBasicProvider dbm + AuthDBMUserFile "/www/passwords/passwd.dbm" + Require valid-user +</Directory> + + +

Hay otras opciones disponibles. Consulta la documentaciÃ³n de + mod_authn_dbm para mÃ¡s detalles.

+ +

Uso de mÃºltiples proveedores + +

Con la introducciÃ³n de la nueva autenticaciÃ³n basada en un proveedor y + una arquitectura de autorizaciÃ³n, ya no estaremos restringidos a un Ãºnico + mÃ©todo de autenticaciÃ³n o autorizaciÃ³n. De hecho, cualquier nÃºmero de + los proveedores pueden ser mezclados y emparejados para ofrecerle + exactamente el esquema que se adapte a sus necesidades. + En el siguiente ejemplo, veremos como ambos proveedores tanto el fichero + como el LDAP son usados en la autenticaciÃ³n: +

+ + +<Directory "/www/docs/private"> + AuthName "Private" + AuthType Basic + AuthBasicProvider file ldap + AuthUserFile "/usr/local/apache/passwd/passwords" + AuthLDAPURL ldap://ldaphost/o=yourorg + Require valid-user +</Directory> + + +

En este ejemplo el fichero, que actÃºa como proveedor, intentarÃ¡ autenticar + primero al usuario. Si no puede autenticar al usuario, el proveedor del LDAP + serÃ¡ llamado para que realice la autenticaciÃ³n. + Esto permite al Ã¡mbito de autenticaciÃ³n ser amplio, si su organizaciÃ³n + implementa mÃ¡s de un tipo de almacÃ©n de autenticaciÃ³n. + Otros escenarios de autenticaciÃ³n y autorizaciÃ³n pueden incluir la + mezcla de un tipo de autenticaciÃ³n con un tipo diferente de autorizaciÃ³n. + Por ejemplo, autenticar contra un fichero de contraseÃ±as pero autorizando + dicho acceso mediante el directorio del LDAP.

+ +

AsÃ como mÃºltiples mÃ©todos y proveedores de autenticaciÃ³n pueden + ser implementados, tambiÃ©n pueden usarse mÃºltiples formas de + autorizaciÃ³n. + En este ejemplo ambos ficheros de autorizaciÃ³n de grupo asÃ como + autorizaciÃ³n de grupo mediante LDAP va a ser usado: +

+ + +<Directory "/www/docs/private"> + AuthName "Private" + AuthType Basic + AuthBasicProvider file + AuthUserFile "/usr/local/apache/passwd/passwords" + AuthLDAPURL ldap://ldaphost/o=yourorg + AuthGroupFile "/usr/local/apache/passwd/groups" + Require group GroupName + Require ldap-group cn=mygroup,o=yourorg +</Directory> + + +

Para llevar la autorizaciÃ³n un poco mÃ¡s lejos, las directivas + de autorizaciÃ³n de contenedores tales como + RequireAll + and + RequireAny + nos permiten aplicar una lÃ³gica de en quÃ© orden se manejarÃ¡ la autorizaciÃ³n dependiendo + de la configuraciÃ³n y controlada a travÃ©s de ella. + Mire tambiÃ©n Contenedores de + AutorizaciÃ³n para ejemplos de cÃ³mo pueden ser aplicados.

+ +

MÃ¡s allÃ¡ de la AutorizaciÃ³n + +

El modo en que la autorizaciÃ³n puede ser aplicada es ahora mucho mÃ¡s flexible + que us solo chequeo contra un almacÃ©n de datos (contraseÃ±as). Ordenando la + lÃ³gica y escoger la forma en que la autorizaciÃ³n es realizada, ahora es posible +

+ +

Aplicando la lÃ³gica y ordenaciÃ³n +

Controlar el cÃ³mo y en quÃ© orden se va a aplicar la autorizaciÃ³n ha + sido un misterio en el pasado. En Apache 2.2 un proveedor del + mecanismo de autenticaciÃ³n fue introducido para disociar el proceso actual + de autenticaciÃ³n y soportar funcionalidad. + Uno de los beneficios secundarios fue que los proveedores de autenticaciÃ³n + podÃan ser configurados y llamados en un orden especifico que no dependieran + en el orden de carga del propio modulo. + Este proveedor de dicho mecanismo, ha sido introducido en la autorizaciÃ³n + tambiÃ©n. Lo que esto significa es que la directiva + Require + no sÃ³lo especifica que mÃ©todo de autorizaciÃ³n deberÃ¡ ser usado, si no + tambiÃ©n especifica el orden en que van a ser llamados. MÃºltiples + mÃ©todos de autorizaciÃ³n son llamados en el mismo orden en que la directiva + Require aparece en la + configuraciÃ³n. +

+ +

+ Con la IntroducciÃ³n del contenedor de directivas de autorizaciÃ³n tales como + RequireAll + y + RequireAny, + La configuraciÃ³n tambiÃ©n tiene control sobre cuÃ¡ndo se llaman a los mÃ©todos + de autorizaciÃ³n y quÃ© criterios determinan cuÃ¡ndo se concede el acceso. + Vease + Contenedores de autorizaciÃ³n + Para un ejemplo de cÃ³mo pueden ser utilizados para expresar una lÃ³gica + mÃ¡s compleja de autorizaciÃ³n. +

+ +

+ Por defecto todas las directivas + Require + son manejadas como si estuvieran contenidas en una directiva + RequireAny. + En otras palabras, Si alguno de los mÃ©todos de autorizaciÃ³n + especificados tiene Ã©xito, se concede la autorizaciÃ³n. +

+ +

Uso de los proveedores de autorizaciÃ³n para + el control de acceso + +

+ La autenticaciÃ³n de nombre de usuario y contraseÃ±a es sÃ³lo parte + de toda la historia que conlleva el proceso. Frecuentemente quiere + dar acceso a la gente en base a algo mÃ¡s que lo que son. + Algo como de donde vienen. +

+ +

+ Los proveedores de autorizaciÃ³n all, + env, host y ip + te permiten denegar o permitir el acceso basÃ¡ndose en otros + criterios como el nombre de la mÃ¡quina o la IP de la mÃ¡quina que + realiza la consulta para un documento. +

+ +

+ El uso de estos proveedores se especifica a travÃ©s de la directiva + Require. + La directiva registra los proveedores de autorizaciÃ³n que serÃ¡n llamados + durante la solicitud de la fase del proceso de autorizaciÃ³n. Por ejemplo: +

+ + +Require ip address + + +

+ Donde address es una direcciÃ³n IP (o una direcciÃ³n IP parcial) + o bien: +

+ + +Require host domain_name + + +

+ Donde domain_name es el nombre completamente cualificado de un nombre + de dominio (FQDN) (o un nombre parcial del dominio); + puede proporcionar mÃºltiples direcciones o nombres de dominio, si se desea. +

+ +

+ Por ejemplo, si alguien envÃa spam a su tablÃ³n de mensajes y desea + mantenerlos alejados, podrÃa hacer lo siguiente:

+ + +<RequireAll> + Require all granted + Require not ip 10.252.46.165 +</RequireAll> + + +

+ Visitantes que vengan desde esa IP no serÃ¡n capaces de ver el contenido + que cubre esta directiva. Si, en cambio, lo que se tiene es el nombre de + la mÃ¡quina, en vez de la direcciÃ³n IP, podrÃa usar: +

+ + +<RequireAll> + Require all granted + Require not host host.example.com +</RequireAll> + + +

+ Y, si lo que se quiere es bloquear el acceso desde un determinado dominio + (bloquear el acceso desde el dominio entero), puede especificar parte + de la direcciÃ³n o del propio dominio a bloquear: +

+ + +<RequireAll> + Require all granted + Require not ip 192.168.205 + Require not host phishers.example.com moreidiots.example + Require not host ke +</RequireAll> + + +

+ Usando RequireAll + con mÃºltiples directivas Require, cada una negada con un not, + SÃ³lo permitirÃ¡ el acceso, si todas las condiciones negadas son verdaderas. + En otras palabras, el acceso serÃ¡ bloqueado, si cualquiera de las condiciones + negadas fallara. +

+ +

Compatibilidad de Control de Acceso con versiones + anteriores + +

+ Uno de los efectos secundarios de adoptar proveedores basados en + mecanismos de autenticaciÃ³n es que las directivas anteriores + Order, + Allow, + Deny y + Satisfy ya no son necesarias. + Sin embargo, para proporcionar compatibilidad con configuraciones antiguas, + estas directivas se han movido al mÃ³dulo mod_access_compat. +

+ + Nota: +

+ Las directivas proporcionadas por mod_access_compat + han quedado obsoletas por mod_authz_host. Mezclar + directivas antiguas como + Order, + Allow Ã³ + Deny con las nuevas + como + Require + es tÃ©cnicamente posible pero desaconsejable. El mÃ³dulo + mod_access_compat se creÃ³ para soportar configuraciones + que contuvieran sÃ³lo directivas antiguas para facilitar la actualizaciÃ³n + a la versiÃ³n 2.4. + Por favor revise la documentaciÃ³n de + actualizaciÃ³n para mÃ¡s informaciÃ³n al + respecto. +

+ +

Cache de AutenticaciÃ³n +

+ Puede haber momentos en que la autenticaciÃ³n ponga una carga + inaceptable en el proveedor (de autenticaciÃ³n) o en tu red. + Esto suele afectar a los usuarios de mod_authn_dbd + (u otros proveedores de terceros/personalizados). + Para lidiar con este problema, HTTPD 2.3/2.4 introduce un nuevo proveedor + de cachÃ© mod_authn_socache para cachear las credenciales + y reducir la carga en el proveedor(es) original. +

+ Esto puede ofrecer un aumento de rendimiento sustancial para algunos usuarios. +

+ +

MÃ¡s informaciÃ³n + +

+ TambiÃ©n deberÃa leer la documentaciÃ³n para + mod_auth_basic y mod_authz_host + la cuÃ¡l contiene mÃ¡s informaciÃ³n de como funciona todo esto. + La directiva AuthnProviderAlias puede tambiÃ©n ayudar + a la hora de simplificar ciertas configuraciones de autenticaciÃ³n. +

+ +

+ Los diferentes algoritmos de cifrado que estÃ¡n soportados por Apache + para la autenticaciÃ³n se explican en + Cifrado de ContraseÃ±as. +

+ +

+ Y tal vez quiera ojear la documentaciÃ³n de "how to" + Control de Acceso donde se mencionan temas + relacionados.

+ +

+ + diff --git a/docs/manual/howto/auth.xml.meta b/docs/manual/howto/auth.xml.meta index 250ddc5cad..1ec45a49e7 100644 --- a/docs/manual/howto/auth.xml.meta +++ b/docs/manual/howto/auth.xml.meta @@ -8,6 +8,7 @@ en + es fr ja ko diff --git a/docs/manual/howto/cgi.html b/docs/manual/howto/cgi.html index 5a965e3380..4f069faacf 100644 --- a/docs/manual/howto/cgi.html +++ b/docs/manual/howto/cgi.html @@ -4,6 +4,10 @@ URI: cgi.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: cgi.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + URI: cgi.html.fr Content-Language: fr Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/howto/cgi.html.es b/docs/manual/howto/cgi.html.es new file mode 100644 index 0000000000..5ead2d908c --- /dev/null +++ b/docs/manual/howto/cgi.html.es @@ -0,0 +1,615 @@ + + + + + +Tutorial de Apache: Contenido Dinámico con CGI - Servidor Apache HTTP Versión 2.4 + + + + + + + +

+Apache > Servidor HTTP > Documentación > Versión 2.4 > How-To / Tutoriales

Tutorial de Apache: Contenido Dinámico con CGI

Idiomas disponibles: en | + es | + fr | + ja | + ko

Introducción
Configurando Apache para permitir CGI
Escribiendo un programa CGI
¡Pero todavía no funciona!
¿Qué ocurre entre bastidores?
Módulos/librerías CGI
Para más información

Consulte también

Comentarios

Introducción

Módulos Relacionados	Directivas Relacionadas
`mod_alias` `mod_cgi` `mod_cgid`	`AddHandler` `Options` `ScriptAlias`

+ + + +

CGI (Common Gateway Interface) es un método por el cual + un servidor web puede interactuar con programas externos de + generación de contenido, a ellos nos referimos comúnmente como + programas CGI o scripts CGI. Es el método más común y sencillo de + mostrar contenido dinámico en su sitio web. Este documento es una + introducción para configurar CGI en su servidor web Apache, y de + iniciación para escribir programas CGI.

Configurando Apache para permitir CGI

+ + +

Para conseguir que sus programas CGI funcionen correctamente, + deberá configurar Apache para que permita la ejecución de CGI. Hay + distintas formas de hacerlo.

+ +

Nota: Si Apache ha sido compilado con soporte + de módulos compartidos, necesitará que el módulo de CGI esté cargado; + en su httpd.conf tiene que asegurarse de que la directiva + LoadModule + no ha sido comentada. Una directiva configurada correctamente sería así: + +

LoadModule cgid_module modules/mod_cgid.so

+ + + En Windows, o si usa un mpm que no es multihilo, como prefork, una + directiva configurada correctamente podría definirse así: + +

LoadModule cgi_module modules/mod_cgi.so

+ +

ScriptAlias

+ + +

La directiva + ScriptAlias + indica a Apache que un directorio se ha configurado específicamente + para programas CGI. Apache asumirá que cada fichero en este + directorio es un programa CGI, e intentará ejecutarlos cuando un + cliente solicita este recurso.

+ +

La directiva + ScriptAlias se puede + definir así:

+ +

ScriptAlias "/cgi-bin/" "/usr/local/apache2/cgi-bin/"

+ + +

El ejemplo que se muestra es de un archivo de configuración + httpd.conf por defecto si usted instaló Apache + en la ubicación por defecto. La directiva + ScriptAlias es muy + parecida a la directiva Alias, + ésta define un prefijo de URL que se enlaza a un directorio + en particular. Alias y + ScriptAlias se usan generalmente para + directorios que se encuentran fuera del directorio + DocumentRoot. La diferencia + entre Alias y ScriptAlias + es que en ScriptAlias cualquier elemento + debajo de ese prefijo de URL será considerado un programa CGI. Así, + el ejemplo de más arriba le indica a Apache que + cualquier solicitud para un recurso que comience con + /cgi-bin/ debería servirse desde el directorio + /usr/local/apache2/cgi-bin/, y debería tratarse como un + programa CGI.

+ +

Por ejemplo, si se solicita la URL + http://www.example.com/cgi-bin/test.pl, + Apache intentará ejecutar el archivo + /usr/local/apache2/cgi-bin/test.pl y dar + el resultado. Por supuesto el archivo debe existir y ser ejecutable, + y dar el resultado de una manera específica o Apache devolverá + un mensaje de error.

+ + +

CGI fuera de directorios ScriptAlias

+ + +

Los programas CGI habitualmente se restringen a los directorios de + ScriptAlias por razones de + seguridad. De esta manera, los administradores pueden controlar de una + manera más segura quien puede ejecutar programas CGI. Aun así, si no + se toman suficientes precauciones, no hay ninguna razón por la que + programas CGI no se puedan ejecutar desde directorios seleccionados de + manera arbitraria. Por ejemplo, quizás quiera permitir que usuarios del + sistema tengan contenido web en sus directorios home con la directiva + UserDir. Si quieren + tener sus propios programas CGI, pero no tienen acceso al directorio + principal cgi-bin, necesitarán ser capaces de + ejecutar sus scripts CGI en algún otro sitio.

+ +

Hay dos pasos a seguir para permitir la ejecución CGI en directorios + seleccionados de manera arbitraria. Primero, el handler + cgi-script debe estar activado usando la directiva + AddHandler o la directiva + SetHandler. Segundo, el parámetro + ExecCGI debe estar definido en la directiva + Options.

+ + +

Usando Options de manera explícita para permitir ejecución de + CGI

+ + +

Puede usar la directiva + Options, en el archivo de + configuración principal para especificar que se permite la ejecución + de CGI en un directorio en particular:

+ +

<Directory "/usr/local/apache2/htdocs/somedir">
+    Options +ExecCGI
+</Directory>

+ + +

Esta directiva de aquí arriba le indica a Apache que debe + permitir la ejecución de archivos CGI. También necesitará indicarle + al servidor que los archivos son archivos CGI. La directiva + AddHandler le indica al + servidor que debe tratar a todos los archivos con la extensión + cgi o pl como programas CGI:

+ +

AddHandler cgi-script .cgi .pl

+ + + +

Ficheros .htaccess

+ + +

El tutorial .htaccess + enseña como activar programas CGI si no tienes acceso a + httpd.conf.

+ + +

Directorios de Usuario

+ + +

Para permitir la ejecución de programas CGI para cualquier + archivo que acabe en .cgi en directorios de usuario, + puedes usar la siguiente configuración:

+ +

<Directory "/home/*/public_html">
+    Options +ExecCGI
+    AddHandler cgi-script .cgi
+</Directory>

+ + +

Si quiere designar un subdirectorio cgi-bin dentro + de un directorio de usuario en el que todos los ficheros serán + tratados como un programa CGI, puede usar lo siguiente:

+ +

<Directory "/home/*/public_html/cgi-bin">
+    Options ExecCGI
+    SetHandler cgi-script
+</Directory>

+ + +

Escribiendo un programa CGI

+ + +

Hay dos diferencias principales entre programación ``regular'' y + programación en CGI.

+ +

Primera, el resultado al completo de tu programa CGI debe estar + precedido de una cabecera MIME-type. Esta + cabecera HTTP le indica al cliente que tipo de contenido está + recibiendo. La mayor parte de las veces, ésto será algo como:

+ +

+ Content-type: text/html +

+ +

Segunda, el resultado debe estar en formato HTML, o cualquier + otro formato que su navegador sea capaz de mostrar. La mayor + parte de las veces, será HTML, pero otras escribirá un programa + CGI que devuelve una imagen gif, u otro contenido no-HTML.

+ +

Aparte de estas dos cosas, escribir un programa en CGI se + parecerá bastante a cualquier otro programa que vaya a escribir. +

+ + +

Su primer programa CGI

+ + +

A continuación podrá ver un ejemplo de programa CGI que muestra + una línea de texto en su navegador. Escriba lo siguiente, + guárdelo en un archivo con el nombre first.pl, y + póngalo en su directorio cgi-bin.

+ +

#!/usr/bin/perl
+print "Content-type: text/html\n\n";
+print "Hola, Mundo.";

+ + +

Incluso si Perl no le resulta familiar, podrá ver lo que está + ocurriendo aquí. La primera línea le dice a Apache (o a + cualquier shell en la que se esté ejecutando) que este programa + puede ejecutarse con el intérprete en la ubicación + /usr/bin/perl. La segunda línea imprime la + declaración de Content-Type que mencionamos antes, seguida de + dos pares de retornos de carro. Esto pone una línea en blanco + después de la cabecera para indicar el final de las cabeceras + HTTP, y el comienzo del cuerpo del contenido. La tercera + imprime la cadena de caracteres "Hola, Mundo.". Y ese es el + final del programa.

+ +

Si lo abre con su navegador favorito y le dice que solicite la + dirección

+ +

+ http://www.example.com/cgi-bin/first.pl +

+ +

o donde quiera que pusiera el archivo, verá una línea + Hola, Mundo. aparecerán la ventana del navegador. No es + muy emocionante, pero una vez que consiga que funcione podrá hacer + lo mismo con casi cualquier programa.

+ +

¡Pero todavía no funciona!

+ + +

Hay 4 cosas básicas que puede llegar a ver en su navegador cuando + intenta acceder a un programa CGI desde la web:

+ +

El resultado del programa CGI: ¡Genial! Esto indica que todo funcionó correctamente. Si el + resultado es correcto, pero el navegador no lo procesa + correctamente, asegúrese de que tiene especificado + correctamente el Content-Type en su programa + CGI.
El código fuente de su programa CGI o un mensaje del tipo + "POST Method Not Allowed".: Eso significa que no ha configurado Apache de manera + apropiada para interpretar su programa CGI. Relea la sección + de Configurando Apache e intente + encontrar qué le falta.
Un mensaje que empieza con "Forbidden": Eso significa que hay un problema de permisos. Compruebe el + Log de Errores de Apache y la + sección de más abajo de Permisos de + Fichero.
Un mensaje indicando "Internal Server Error": Si comprueba el Log de errores de + Apache, probablemente encontrará que indica "Premature + end of script headers", posiblemente acompañado de otro + mensaje de error generado por su programa CGI. En este caso, + querrá comprobar cada una de las secciones de más adelante + para ver qué impide que su programa CGI genere las cabeceras + HTTP adecuadas.

+ +

Permisos de Fichero

+ + +

Recuerde que el servidor no se ejecuta con su usuario. Es decir, + cuando el servidor arranca, está funcionando con un usuario sin + privilegios, generalmente el usuario nobody, o + www-data, así que necesitará permisos extra para + ejecutar los archivos de los que usted es dueño. Generalmente, + el método para dar permisos suficientes para que se pueda + ejecutar con nobody es dar permisos de ejecución a + todo el mundo en el fichero:

+ +

+ chmod a+x first.pl +

+ +

Además, si su programa lee desde o escribe a cualquier otro/s + archivo/s, esos archivos necesitarán tener los permisos correctos + para permitir esas acciones.

+ + + +

Información de Ruta y Entorno

+ + +

Cuando ejecuta un programa desde la línea de comandos, usted tiene + cierta información que se le pasa a la shell sin que usted se + percate de ello. Por ejemplo, usted tiene un PATH, + que le indica a la shell dónde debe buscar archivos a los que usted + hace referencia.

+ +

Cuando un programa se ejecuta a través del servidor web como un + programa CGI, puede que no tenga el mismo PATH. + Cualquier programa que invoque desde su programa CGI (como por + ejemplo sendmail) necesitará que se le indique la + ruta absoluta, así la shell puede encontrarlos cuando intenta + ejecutar su programa CGI.

+ +

Una manifestación común de esto es la ruta del intérprete del + script (a menudo perl) indicado en la primera línea + de su programa CGI, que parecerá algo como:

+ +

#!/usr/bin/perl

+ + +

Asegúrese de que éste es de hecho el path de su intérprete.

+ Cuando edita scripts CGI en Windows, los caracteres de retorno de + carro podrían añadirse a la línea donde se especifica el intérprete. + Asegúrese de que los archivos se transfieren al servidor en modo + ASCII. Fallar en esto puede acabar con avisos del tipo "Command not + found" del Sistema Operativo, debido a que éste no reconoce los + caracteres de final de línea interpretados como parte del nombre + de fichero del intérprete. +

+ + +

Faltan Variables de Entorno

+ + +

Si su programa CGI depende de variables de entorno no estándar, necesitará + asegurarse de que Apache pasa esas variables.

+ +

Cuando no encuentra ciertas cabeceras HTTP del entorno, asegúrese + de que están formateadas según el + RFC 2616, + sección 4.2: Nombres de Cabeceras deben empezar con una letra, + seguida solo de letras, números o guión. Cualquier cabecera + que no cumpla esta regla será ignorada de manera silenciosa.

+ + + +

Errores de Programa

+ + +

La mayor parte de las veces cuando un programa CGI falla, es por un + problema en el programa mismo. Esto ocurre generalmente cuando se + maneja bien con "esto del CGI", y ya no comete los dos errores + mencionados más arriba. Lo primero que hay que hacer es asegurarse + de que su programa se ejecuta correctamente en línea de comandos + antes de probarlo a través del servidor web. Por ejemplo, + intente:

+ +

+ cd /usr/local/apache2/cgi-bin + ./first.pl +

+ +

(No llame al intérprete de perl. La consola y Apache + tienen que poder encontrar el intérprete usando línea + línea de información en la primera + línea del script.)

+ +

Lo primero que debe ver escrito por su programa es un conjunto de + cabeceras HTTP, incluyendo el Content-Type, + seguido de una línea en blanco. Si ve alguna otra cosa, Apache + devolverá el error Premature end of script headers si + intenta lanzar el script en el servidor web. Vea + Escribiendo un programa CGI más arriba para + más detalle.

+ + +

Log de Errores

+ + +

El log de errores es su amigo. Cualquier cosa que vaya mal generará + un mensaje en el log de errores. Debería mirar siempre ahí primero. + Si el lugar donde está alojando su sitio web no permite que acceda + al log de errores, probablemente debería alojarlo en otro sitio. + Aprenda a leer el log de errores y se dará cuenta de que enseguida + averiguará el motivo del error y lo solucionará rápidamente.

+ + +

Suexec

+ + +

El programa de soporte suexec permite + que programas CGI se ejecuten con permisos de usuario distintos, + dependiendo del virtualhost o el directorio home donde se + encuentren. Suexec tiene una comprobación de permisos muy estricta, + y cualquier fallo en esa comprobación dará como resultado un error + con el mensaje Premature end of script headers.

+ +

Para comprobar si está usando Suexec, ejecute + apachectl -V y compruebe la ubicación de + SUEXEC_BIN. Si Apache encuentra un binario + suexec al arrancar, suexec se activará.

+ +

A menos que comprenda suxec perfectamente, no debería usarlo. + Para desactivar suexec, basta con eliminar el binario + suexec al que apunta SUEXEC_BIN y + reiniciar el servidor. Si después de leer sobre + suexec todavía quiere usarlo, entonces + ejecute suexec -V para encontrar la ubicación del + fichero log de suexec, y use ese log para encontrar que política no + está cumpliendo.

+ +

¿Qué ocurre entre bastidores?

+ + +

En cuanto tenga conocimiento avanzado de programación CGI, le será + útil comprender más de lo que ocurre entre bastidores. + Específicamente, cómo el navegador y el servidor se comunican el uno + con el otro. Porque aunque esté muy bien escribir un programa que + diga "Hola, Mundo.", no tiene una gran utilidad.

+ +

Variables de Entorno

+ + +

Las variables de entorno son valores que están ahí cuando + usa el ordenador. Son cosas útiles como el path (donde su ordenador + busca el archivo específico que se lanza cuando usted escribe un + comando), su nombre de usuario, el tipo de terminal que usa, etc. + Para una lista completa de la variables de entorno normales que se + se usan en su día a día escriba env en la línea de + comandos.

+ +

Durante la transacción CGI, el servidor y el navegador también + configuran variables de entorno, y así pueden comunicarse entre + ellos. Cosas como el tipo de navegador (Netscape, IE, Lynx), el tipo + de servidor (Apache, IIS, WebSite), el nombre del programa CGI que + se está ejecutando, etc.

+ +

Estas variables están disponibles para el programador de CGI, y son + la mitad de la historia de la comunicación cliente-servidor. La + lista completa de las variables necesarias se encuentra en + el RFC de Common Gateway + Interface.

+ +

Este sencillo programa CGI en Perl mostrará todas las variables + de entorno que se están pasando entre el cliente y el navegador. Dos + programas similares están incluidos en el directorio + cgi-bin de la distribución de Apache. Tenga en cuenta + que algunas variables son necesarias mientras que otras son + opcionales, así que es posible que vea algunas variables que no + están en la lista oficial. Adicionalmente, Apache aporta distintas + maneras diferentes para que pueda + añadir sus variables de entorno a las + básicas que se proveen por defecto.

+ +

#!/usr/bin/perl
+use strict;
+use warnings;
+
+print "Content-type: text/html\n\n";
+          
+foreach my $key (keys %ENV) {
+    print "$key --> $ENV{$key}<br>";
+}

+ + + +

STDIN y STDOUT

+ + +

Otra comunicación entre el servidor y el cliente ocurre en la + entrada estándar (STDIN) y la salida estándar + (STDOUT). En el contexto normal de cada día, + STDIN es la entrada con el teclado, o un fichero que se + le da a un programa para que actúe sobre él, y STDOUT + generalmente es la consola o la pantalla.

+ +

Cuando hace POST con un formulario de web a un programa + CGI, los datos en ese formulario se empaquetan en un formato especial + que se entrega a su programa CGI en el STDIN. + Entonces el programa puede procesar la información como si le llegara + desde el teclado, o desde un fichero.

+ +

El "formato especial" es muy sencillo. Un nombre de campo y su + valor se asocian juntos con el signo igual (=), y pares de valores + se asocian juntos con el ampersand ó et en español (&). + Caracteres inconvenientes como los espacios, ampersands y signos de + igual, se convierten en su equivalente hexadecimal para no impidan + el funcionamiento correcto del programa. La cadena de datos al + completo será algo como:

+ +

+ name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey +

+ +

A veces tendrá este tipo de cadena de caracteres al final de una + URL. Cuando esto ocurre, el servidor pone esa cadena en una variable + de entorno que se llama QUERY_STRING. Esto se llama + solicitud GET. Su formulario HTML especifica si se usa + un GET o un POST para entregar la + información, configurando el atributo METHOD en la + etiqueta FORM.

+ +

Su programa es el responsable de convertir esa cadena de + caracteres en información útil. Afortunadamente, hay librerías y + módulos disponibles que ayudan a procesar la información, así como a + gestionar los distintos aspectos de su programa CGI.

+ +

Módulos/librerías CGI

+ + +

Cuando escribe programas CGI, debería considerar usar una librería de + código, o módulo, para hacer todo el trabajo más arduo por usted. + Esto lleva a tener menos errores y un desarrollo de código más + rápido.

+ +

Si está escribiendo un programa CGI en Perl, existen módulos + disponibles en CPAN. El módulo más + conocido para este propósito es CGI.pm. Quizás quiera + considerar CGI::Lite, que implementa una funcionalidad + mínima, que es todo lo que se necesita en la mayoría de los programas.

+ +

Si está escribiendo programas CGI en C, hay varidad de opciones. Una + de estas es la librería CGIC, de + http://www.boutell.com/cgic/. +

Para más información

+ + +

La especificación actual de CGI está disponible en el + RFC de Common Gateway + Interface.

+ +

Cuando envíe una pregunta sobre un problema de CGI, o bien a una + lista de correo, o a un grupo de noticias, asegúrese de que facilita suficiente + información de lo que ha ocurrido, de lo que espera que ocurra, y de + lo que está ocurriendo en su lugar que es diferente, el servidor que + está ejecutando, en qué lenguaje CGI está hecho su programa, y si es + posible, el código que falla. Esto hará encontrar el problema mucho más + fácil.

+ +

Tenga en cuenta que las preguntas sobre problemas CGI + nunca deberían enviarse a la base de datos de bugs de + bugs de Apache a menos que esté seguro de haber encontrado un + problema en el código fuente de Apache.

Idiomas disponibles: en | + es | + fr | + ja | + ko

Comentarios

+ \ No newline at end of file diff --git a/docs/manual/howto/cgi.xml.es b/docs/manual/howto/cgi.xml.es new file mode 100644 index 0000000000..90eed02716 --- /dev/null +++ b/docs/manual/howto/cgi.xml.es @@ -0,0 +1,594 @@ + + + + + + + + + + + How-To / Tutoriales + Tutorial de Apache: Contenido DinÃ¡mico con CGI + +

+ IntroducciÃ³n + + + mod_alias + mod_cgi + mod_cgid + + + + AddHandler + Options + ScriptAlias + + + +

CGI (Common Gateway Interface) es un mÃ©todo por el cual + un servidor web puede interactuar con programas externos de + generaciÃ³n de contenido, a ellos nos referimos comÃºnmente como + programas CGI o scripts CGI. Es el mÃ©todo mÃ¡s comÃºn y sencillo de + mostrar contenido dinÃ¡mico en su sitio web. Este documento es una + introducciÃ³n para configurar CGI en su servidor web Apache, y de + iniciaciÃ³n para escribir programas CGI.

+ +

+ Configurando Apache para permitir CGI + +

Para conseguir que sus programas CGI funcionen correctamente, + deberÃ¡ configurar Apache para que permita la ejecuciÃ³n de CGI. Hay + distintas formas de hacerlo.

+ + Nota: Si Apache ha sido compilado con soporte + de mÃ³dulos compartidos, necesitarÃ¡ que el mÃ³dulo de CGI estÃ© cargado; + en su httpd.conf tiene que asegurarse de que la directiva + LoadModule + no ha sido comentada. Una directiva configurada correctamente serÃa asÃ: + + + LoadModule cgid_module modules/mod_cgid.so + + + En Windows, o si usa un mpm que no es multihilo, como prefork, una + directiva configurada correctamente podrÃa definirse asÃ: + + + LoadModule cgi_module modules/mod_cgi.so + + +

+ ScriptAlias + +

La directiva + ScriptAlias + indica a Apache que un directorio se ha configurado especÃficamente + para programas CGI. Apache asumirÃ¡ que cada fichero en este + directorio es un programa CGI, e intentarÃ¡ ejecutarlos cuando un + cliente solicita este recurso.

+ +

La directiva + ScriptAlias se puede + definir asÃ:

+ + + ScriptAlias "/cgi-bin/" "/usr/local/apache2/cgi-bin/" + + +

El ejemplo que se muestra es de un archivo de configuraciÃ³n + httpd.conf por defecto si usted instalÃ³ Apache + en la ubicaciÃ³n por defecto. La directiva + ScriptAlias es muy + parecida a la directiva Alias, + Ã©sta define un prefijo de URL que se enlaza a un directorio + en particular. Alias y + ScriptAlias se usan generalmente para + directorios que se encuentran fuera del directorio + DocumentRoot. La diferencia + entre Alias y ScriptAlias + es que en ScriptAlias cualquier elemento + debajo de ese prefijo de URL serÃ¡ considerado un programa CGI. AsÃ, + el ejemplo de mÃ¡s arriba le indica a Apache que + cualquier solicitud para un recurso que comience con + /cgi-bin/ deberÃa servirse desde el directorio + /usr/local/apache2/cgi-bin/, y deberÃa tratarse como un + programa CGI.

+ +

Por ejemplo, si se solicita la URL + http://www.example.com/cgi-bin/test.pl, + Apache intentarÃ¡ ejecutar el archivo + /usr/local/apache2/cgi-bin/test.pl y dar + el resultado. Por supuesto el archivo debe existir y ser ejecutable, + y dar el resultado de una manera especÃfica o Apache devolverÃ¡ + un mensaje de error.

+ +

+ CGI fuera de directorios ScriptAlias + +

Los programas CGI habitualmente se restringen a los directorios de + ScriptAlias por razones de + seguridad. De esta manera, los administradores pueden controlar de una + manera mÃ¡s segura quien puede ejecutar programas CGI. Aun asÃ, si no + se toman suficientes precauciones, no hay ninguna razÃ³n por la que + programas CGI no se puedan ejecutar desde directorios seleccionados de + manera arbitraria. Por ejemplo, quizÃ¡s quiera permitir que usuarios del + sistema tengan contenido web en sus directorios home con la directiva + UserDir. Si quieren + tener sus propios programas CGI, pero no tienen acceso al directorio + principal cgi-bin, necesitarÃ¡n ser capaces de + ejecutar sus scripts CGI en algÃºn otro sitio.

+ +

Hay dos pasos a seguir para permitir la ejecuciÃ³n CGI en directorios + seleccionados de manera arbitraria. Primero, el handler + cgi-script debe estar activado usando la directiva + AddHandler o la directiva + SetHandler. Segundo, el parÃ¡metro + ExecCGI debe estar definido en la directiva + Options.

+ +

+ Usando Options de manera explÃcita para permitir ejecuciÃ³n de + CGI + +

Puede usar la directiva + Options, en el archivo de + configuraciÃ³n principal para especificar que se permite la ejecuciÃ³n + de CGI en un directorio en particular:

+ + +<Directory "/usr/local/apache2/htdocs/somedir"> + Options +ExecCGI +</Directory> + + +

Esta directiva de aquÃ arriba le indica a Apache que debe + permitir la ejecuciÃ³n de archivos CGI. TambiÃ©n necesitarÃ¡ indicarle + al servidor que los archivos son archivos CGI. La directiva + AddHandler le indica al + servidor que debe tratar a todos los archivos con la extensiÃ³n + cgi o pl como programas CGI:

+ + + AddHandler cgi-script .cgi .pl + +

+ +

+ Ficheros .htaccess + +

El tutorial .htaccess + enseÃ±a como activar programas CGI si no tienes acceso a + httpd.conf.

+ +

+ Directorios de Usuario + +

Para permitir la ejecuciÃ³n de programas CGI para cualquier + archivo que acabe en .cgi en directorios de usuario, + puedes usar la siguiente configuraciÃ³n:

+ + +<Directory "/home/*/public_html"> + Options +ExecCGI + AddHandler cgi-script .cgi +</Directory> + + +

Si quiere designar un subdirectorio cgi-bin dentro + de un directorio de usuario en el que todos los ficheros serÃ¡n + tratados como un programa CGI, puede usar lo siguiente:

+ + +<Directory "/home/*/public_html/cgi-bin"> + Options ExecCGI + SetHandler cgi-script +</Directory> + +

+ +

+ Escribiendo un programa CGI + +

Hay dos diferencias principales entre programaciÃ³n ``regular'' y + programaciÃ³n en CGI.

+ +

Primera, el resultado al completo de tu programa CGI debe estar + precedido de una cabecera MIME-type. Esta + cabecera HTTP le indica al cliente que tipo de contenido estÃ¡ + recibiendo. La mayor parte de las veces, Ã©sto serÃ¡ algo como:

+ + + Content-type: text/html + + +

Segunda, el resultado debe estar en formato HTML, o cualquier + otro formato que su navegador sea capaz de mostrar. La mayor + parte de las veces, serÃ¡ HTML, pero otras escribirÃ¡ un programa + CGI que devuelve una imagen gif, u otro contenido no-HTML.

+ +

Aparte de estas dos cosas, escribir un programa en CGI se + parecerÃ¡ bastante a cualquier otro programa que vaya a escribir. +

+ + +

+ Su primer programa CGI + +

A continuaciÃ³n podrÃ¡ ver un ejemplo de programa CGI que muestra + una lÃnea de texto en su navegador. Escriba lo siguiente, + guÃ¡rdelo en un archivo con el nombre first.pl, y + pÃ³ngalo en su directorio cgi-bin.

+ + +#!/usr/bin/perl +print "Content-type: text/html\n\n"; +print "Hola, Mundo."; + + +

Incluso si Perl no le resulta familiar, podrÃ¡ ver lo que estÃ¡ + ocurriendo aquÃ. La primera lÃnea le dice a Apache (o a + cualquier shell en la que se estÃ© ejecutando) que este programa + puede ejecutarse con el intÃ©rprete en la ubicaciÃ³n + /usr/bin/perl. La segunda lÃnea imprime la + declaraciÃ³n de Content-Type que mencionamos antes, seguida de + dos pares de retornos de carro. Esto pone una lÃnea en blanco + despuÃ©s de la cabecera para indicar el final de las cabeceras + HTTP, y el comienzo del cuerpo del contenido. La tercera + imprime la cadena de caracteres "Hola, Mundo.". Y ese es el + final del programa.

+ +

Si lo abre con su navegador favorito y le dice que solicite la + direcciÃ³n

+ + + http://www.example.com/cgi-bin/first.pl + + +

o donde quiera que pusiera el archivo, verÃ¡ una lÃnea + Hola, Mundo. aparecerÃ¡n la ventana del navegador. No es + muy emocionante, pero una vez que consiga que funcione podrÃ¡ hacer + lo mismo con casi cualquier programa.

+ +

+ Â¡Pero todavÃa no funciona! + +

Hay 4 cosas bÃ¡sicas que puede llegar a ver en su navegador cuando + intenta acceder a un programa CGI desde la web:

+ +

El resultado del programa CGI: Â¡Genial! Esto indica que todo funcionÃ³ correctamente. Si el + resultado es correcto, pero el navegador no lo procesa + correctamente, asegÃºrese de que tiene especificado + correctamente el Content-Type en su programa + CGI.
El cÃ³digo fuente de su programa CGI o un mensaje del tipo + "POST Method Not Allowed".: Eso significa que no ha configurado Apache de manera + apropiada para interpretar su programa CGI. Relea la secciÃ³n + de Configurando Apache e intente + encontrar quÃ© le falta.
Un mensaje que empieza con "Forbidden": Eso significa que hay un problema de permisos. Compruebe el + Log de Errores de Apache y la + secciÃ³n de mÃ¡s abajo de Permisos de + Fichero.
Un mensaje indicando "Internal Server Error": Si comprueba el Log de errores de + Apache, probablemente encontrarÃ¡ que indica "Premature + end of script headers", posiblemente acompaÃ±ado de otro + mensaje de error generado por su programa CGI. En este caso, + querrÃ¡ comprobar cada una de las secciones de mÃ¡s adelante + para ver quÃ© impide que su programa CGI genere las cabeceras + HTTP adecuadas.

+ +

+ Permisos de Fichero + +

Recuerde que el servidor no se ejecuta con su usuario. Es decir, + cuando el servidor arranca, estÃ¡ funcionando con un usuario sin + privilegios, generalmente el usuario nobody, o + www-data, asÃ que necesitarÃ¡ permisos extra para + ejecutar los archivos de los que usted es dueÃ±o. Generalmente, + el mÃ©todo para dar permisos suficientes para que se pueda + ejecutar con nobody es dar permisos de ejecuciÃ³n a + todo el mundo en el fichero:

+ + + chmod a+x first.pl + + +

AdemÃ¡s, si su programa lee desde o escribe a cualquier otro/s + archivo/s, esos archivos necesitarÃ¡n tener los permisos correctos + para permitir esas acciones.

+ +

+ InformaciÃ³n de Ruta y Entorno + +

Cuando ejecuta un programa desde la lÃnea de comandos, usted tiene + cierta informaciÃ³n que se le pasa a la shell sin que usted se + percate de ello. Por ejemplo, usted tiene un PATH, + que le indica a la shell dÃ³nde debe buscar archivos a los que usted + hace referencia.

+ +

Cuando un programa se ejecuta a travÃ©s del servidor web como un + programa CGI, puede que no tenga el mismo PATH. + Cualquier programa que invoque desde su programa CGI (como por + ejemplo sendmail) necesitarÃ¡ que se le indique la + ruta absoluta, asÃ la shell puede encontrarlos cuando intenta + ejecutar su programa CGI.

+ +

Una manifestaciÃ³n comÃºn de esto es la ruta del intÃ©rprete del + script (a menudo perl) indicado en la primera lÃnea + de su programa CGI, que parecerÃ¡ algo como:

+ + + #!/usr/bin/perl + + +

AsegÃºrese de que Ã©ste es de hecho el path de su intÃ©rprete.

+ + Cuando edita scripts CGI en Windows, los caracteres de retorno de + carro podrÃan aÃ±adirse a la lÃnea donde se especifica el intÃ©rprete. + AsegÃºrese de que los archivos se transfieren al servidor en modo + ASCII. Fallar en esto puede acabar con avisos del tipo "Command not + found" del Sistema Operativo, debido a que Ã©ste no reconoce los + caracteres de final de lÃnea interpretados como parte del nombre + de fichero del intÃ©rprete. + +

+ +

+ Faltan Variables de Entorno + +

Si su programa CGI depende de variables de entorno no estÃ¡ndar, necesitarÃ¡ + asegurarse de que Apache pasa esas variables.

+ +

Cuando no encuentra ciertas cabeceras HTTP del entorno, asegÃºrese + de que estÃ¡n formateadas segÃºn el + RFC 2616, + secciÃ³n 4.2: Nombres de Cabeceras deben empezar con una letra, + seguida solo de letras, nÃºmeros o guiÃ³n. Cualquier cabecera + que no cumpla esta regla serÃ¡ ignorada de manera silenciosa.

+ +

+ Errores de Programa + +

La mayor parte de las veces cuando un programa CGI falla, es por un + problema en el programa mismo. Esto ocurre generalmente cuando se + maneja bien con "esto del CGI", y ya no comete los dos errores + mencionados mÃ¡s arriba. Lo primero que hay que hacer es asegurarse + de que su programa se ejecuta correctamente en lÃnea de comandos + antes de probarlo a travÃ©s del servidor web. Por ejemplo, + intente:

+ + + cd /usr/local/apache2/cgi-bin
+ ./first.pl + + +

(No llame al intÃ©rprete de perl. La consola y Apache + tienen que poder encontrar el intÃ©rprete usando lÃnea + lÃnea de informaciÃ³n en la primera + lÃnea del script.)

+ +

Lo primero que debe ver escrito por su programa es un conjunto de + cabeceras HTTP, incluyendo el Content-Type, + seguido de una lÃnea en blanco. Si ve alguna otra cosa, Apache + devolverÃ¡ el error Premature end of script headers si + intenta lanzar el script en el servidor web. Vea + Escribiendo un programa CGI mÃ¡s arriba para + mÃ¡s detalle.

+ +

+ Log de Errores + +

El log de errores es su amigo. Cualquier cosa que vaya mal generarÃ¡ + un mensaje en el log de errores. DeberÃa mirar siempre ahÃ primero. + Si el lugar donde estÃ¡ alojando su sitio web no permite que acceda + al log de errores, probablemente deberÃa alojarlo en otro sitio. + Aprenda a leer el log de errores y se darÃ¡ cuenta de que enseguida + averiguarÃ¡ el motivo del error y lo solucionarÃ¡ rÃ¡pidamente.

+ +

+ Suexec + +

El programa de soporte suexec permite + que programas CGI se ejecuten con permisos de usuario distintos, + dependiendo del virtualhost o el directorio home donde se + encuentren. Suexec tiene una comprobaciÃ³n de permisos muy estricta, + y cualquier fallo en esa comprobaciÃ³n darÃ¡ como resultado un error + con el mensaje Premature end of script headers.

+ +

Para comprobar si estÃ¡ usando Suexec, ejecute + apachectl -V y compruebe la ubicaciÃ³n de + SUEXEC_BIN. Si Apache encuentra un binario + suexec al arrancar, suexec se activarÃ¡.

+ +

A menos que comprenda suxec perfectamente, no deberÃa usarlo. + Para desactivar suexec, basta con eliminar el binario + suexec al que apunta SUEXEC_BIN y + reiniciar el servidor. Si despuÃ©s de leer sobre + suexec todavÃa quiere usarlo, entonces + ejecute suexec -V para encontrar la ubicaciÃ³n del + fichero log de suexec, y use ese log para encontrar que polÃtica no + estÃ¡ cumpliendo.

+ +

+ Â¿QuÃ© ocurre entre bastidores? + +

En cuanto tenga conocimiento avanzado de programaciÃ³n CGI, le serÃ¡ + Ãºtil comprender mÃ¡s de lo que ocurre entre bastidores. + EspecÃficamente, cÃ³mo el navegador y el servidor se comunican el uno + con el otro. Porque aunque estÃ© muy bien escribir un programa que + diga "Hola, Mundo.", no tiene una gran utilidad.

+ +

+ Variables de Entorno + +

Las variables de entorno son valores que estÃ¡n ahÃ cuando + usa el ordenador. Son cosas Ãºtiles como el path (donde su ordenador + busca el archivo especÃfico que se lanza cuando usted escribe un + comando), su nombre de usuario, el tipo de terminal que usa, etc. + Para una lista completa de la variables de entorno normales que se + se usan en su dÃa a dÃa escriba env en la lÃnea de + comandos.

+ +

Durante la transacciÃ³n CGI, el servidor y el navegador tambiÃ©n + configuran variables de entorno, y asÃ pueden comunicarse entre + ellos. Cosas como el tipo de navegador (Netscape, IE, Lynx), el tipo + de servidor (Apache, IIS, WebSite), el nombre del programa CGI que + se estÃ¡ ejecutando, etc.

+ +

Estas variables estÃ¡n disponibles para el programador de CGI, y son + la mitad de la historia de la comunicaciÃ³n cliente-servidor. La + lista completa de las variables necesarias se encuentra en + el RFC de Common Gateway + Interface.

+ +

Este sencillo programa CGI en Perl mostrarÃ¡ todas las variables + de entorno que se estÃ¡n pasando entre el cliente y el navegador. Dos + programas similares estÃ¡n incluidos en el directorio + cgi-bin de la distribuciÃ³n de Apache. Tenga en cuenta + que algunas variables son necesarias mientras que otras son + opcionales, asÃ que es posible que vea algunas variables que no + estÃ¡n en la lista oficial. Adicionalmente, Apache aporta distintas + maneras diferentes para que pueda + aÃ±adir sus variables de entorno a las + bÃ¡sicas que se proveen por defecto.

+ + +#!/usr/bin/perl +use strict; +use warnings; + +print "Content-type: text/html\n\n"; + +foreach my $key (keys %ENV) { + print "$key --> $ENV{$key}<br>"; +} + +

+ +

+ STDIN y STDOUT + +

Otra comunicaciÃ³n entre el servidor y el cliente ocurre en la + entrada estÃ¡ndar (STDIN) y la salida estÃ¡ndar + (STDOUT). En el contexto normal de cada dÃa, + STDIN es la entrada con el teclado, o un fichero que se + le da a un programa para que actÃºe sobre Ã©l, y STDOUT + generalmente es la consola o la pantalla.

+ +

Cuando hace POST con un formulario de web a un programa + CGI, los datos en ese formulario se empaquetan en un formato especial + que se entrega a su programa CGI en el STDIN. + Entonces el programa puede procesar la informaciÃ³n como si le llegara + desde el teclado, o desde un fichero.

+ +

El "formato especial" es muy sencillo. Un nombre de campo y su + valor se asocian juntos con el signo igual (=), y pares de valores + se asocian juntos con el ampersand Ã³ et en espaÃ±ol (&). + Caracteres inconvenientes como los espacios, ampersands y signos de + igual, se convierten en su equivalente hexadecimal para no impidan + el funcionamiento correcto del programa. La cadena de datos al + completo serÃ¡ algo como:

+ + + name=Rich%20Bowen&city=Lexington&state=KY&sidekick=Squirrel%20Monkey + + +

A veces tendrÃ¡ este tipo de cadena de caracteres al final de una + URL. Cuando esto ocurre, el servidor pone esa cadena en una variable + de entorno que se llama QUERY_STRING. Esto se llama + solicitud GET. Su formulario HTML especifica si se usa + un GET o un POST para entregar la + informaciÃ³n, configurando el atributo METHOD en la + etiqueta FORM.

+ +

Su programa es el responsable de convertir esa cadena de + caracteres en informaciÃ³n Ãºtil. Afortunadamente, hay librerÃas y + mÃ³dulos disponibles que ayudan a procesar la informaciÃ³n, asÃ como a + gestionar los distintos aspectos de su programa CGI.

+ +

+ MÃ³dulos/librerÃas CGI + +

Cuando escribe programas CGI, deberÃa considerar usar una librerÃa de + cÃ³digo, o mÃ³dulo, para hacer todo el trabajo mÃ¡s arduo por usted. + Esto lleva a tener menos errores y un desarrollo de cÃ³digo mÃ¡s + rÃ¡pido.

+ +

Si estÃ¡ escribiendo un programa CGI en Perl, existen mÃ³dulos + disponibles en CPAN. El mÃ³dulo mÃ¡s + conocido para este propÃ³sito es CGI.pm. QuizÃ¡s quiera + considerar CGI::Lite, que implementa una funcionalidad + mÃnima, que es todo lo que se necesita en la mayorÃa de los programas.

+ +

Si estÃ¡ escribiendo programas CGI en C, hay varidad de opciones. Una + de estas es la librerÃa CGIC, de + http://www.boutell.com/cgic/. +

+ +

+ Para mÃ¡s informaciÃ³n + +

La especificaciÃ³n actual de CGI estÃ¡ disponible en el + RFC de Common Gateway + Interface.

+ +

Cuando envÃe una pregunta sobre un problema de CGI, o bien a una + lista de correo, o a un grupo de noticias, asegÃºrese de que facilita suficiente + informaciÃ³n de lo que ha ocurrido, de lo que espera que ocurra, y de + lo que estÃ¡ ocurriendo en su lugar que es diferente, el servidor que + estÃ¡ ejecutando, en quÃ© lenguaje CGI estÃ¡ hecho su programa, y si es + posible, el cÃ³digo que falla. Esto harÃ¡ encontrar el problema mucho mÃ¡s + fÃ¡cil.

+ +

Tenga en cuenta que las preguntas sobre problemas CGI + nunca deberÃan enviarse a la base de datos de bugs de + bugs de Apache a menos que estÃ© seguro de haber encontrado un + problema en el cÃ³digo fuente de Apache.

+ diff --git a/docs/manual/howto/cgi.xml.meta b/docs/manual/howto/cgi.xml.meta index 3070905d45..7eaed2ca20 100644 --- a/docs/manual/howto/cgi.xml.meta +++ b/docs/manual/howto/cgi.xml.meta @@ -8,6 +8,7 @@ en + es fr ja ko diff --git a/docs/manual/howto/htaccess.html b/docs/manual/howto/htaccess.html index afb2b04fe2..f9aa7ff1aa 100644 --- a/docs/manual/howto/htaccess.html +++ b/docs/manual/howto/htaccess.html @@ -4,6 +4,10 @@ URI: htaccess.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: htaccess.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + URI: htaccess.html.fr Content-Language: fr Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/howto/htaccess.html.es b/docs/manual/howto/htaccess.html.es new file mode 100644 index 0000000000..f4db6d769c --- /dev/null +++ b/docs/manual/howto/htaccess.html.es @@ -0,0 +1,464 @@ + + + + + +Tutorial del Servidor Apache HTTP: Ficheros .htaccess - Servidor Apache HTTP Versión 2.4 + + + + + + + +

+Apache > Servidor HTTP > Documentación > Versión 2.4 > How-To / Tutoriales

Tutorial del Servidor Apache HTTP: Ficheros .htaccess

Idiomas disponibles: en | + es | + fr | + ja | + ko | + pt-br

+ +

Los ficheros .htaccess facilitan una forma de realizar + cambios en la configuración en contexto directorio.

Ficheros .htaccess
Qué son/Cómo usarlos
Cuando (no) usar ficheros .htaccess
How directives are applied
Ejemplo de Autenticación
Ejemplo de Server Side Includes
Reglas de Rewrite en ficheros .htaccess
Ejemplo de CGI
Resolución de problemas

Consulte también

Comentarios

Ficheros .htaccess

Módulos Relacionados	Directivas Relacionadas
`core` `mod_authn_file` `mod_authz_groupfile` `mod_cgi` `mod_include` `mod_mime`	`AccessFileName` `AllowOverride` `Options` `AddHandler` `SetHandler` `AuthType` `AuthName` `AuthUserFile` `AuthGroupFile` `Require`

+ +

Debería evitar usar ficheros .htaccess completamente si + tiene acceso al fichero de configuración principal de httpd. Usar ficheros + .htaccess ralentiza su servidor Apache http. Cualquier + directiva que pueda incluir en un fichero .htaccess + estará mejor configurada dentro de una sección + Directory, tendrá el mismo efecto y + mejor rendimiento.

Qué son/Cómo usarlos

+ + +

Los ficheros .htaccess (o "ficheros de configuración + distribuida") facilitan una forma de realizar cambios en la configuración + en contexto directorio. Un fichero, que contiene una o más directivas, se + coloca en un documento específico de un directorio, y estas directivas + aplican a ese directorio y todos sus subdirectorios.

+ +

Nota:

Si quiere llamar a su fichero .htaccess de otra manera, + puede cambiar el nombre del fichero usando la directiva AccessFileName. Por ejemplo, si usted prefiere + llamar al fichero .config, entonces puede poner lo siguiente + en el fichero de configuración de su servidor:

+ +

AccessFileName ".config"

+ +

Generalmente, los ficheros .htaccess usan la misma sintáxis + que los ficheros de la configuración + principal. Lo que puede utilizar en estos ficheros lo determina la + directiva AllowOverride. Esta directiva + especifica, en categorías, qué directivas tendrán efecto si se encuentran en + un fichero .htaccess. Si se permite una directiva en un fichero + .htaccess, la documentación para esa directiva contendrá una + sección Override, especificando qué valor debe ir en + AllowOverride para que se permita esa + directiva.

+ +

Por ejemplo, si busca en la documentación la directiva AddDefaultCharset, encontrará que se permite en + ficheros .htaccess. (Vea la línea de Contexto en el sumario de + la directiva.) La línea Override muestra + FileInfo. De este modo, debe tener al menos + AllowOverride FileInfo para que esta directiva se aplique en + ficheros .htaccess.

+ +

Ejemplo:

+ + + + + + + + + +

Context:	server config, virtual host, directory, .htaccess
Override:	FileInfo

+ +

Si no está seguro de cuándo, una directiva en concreto, se puede usar en un + fichero .htaccess, consulte la documentación para esa directiva, + y compruebe la línea Context buscando ".htaccess".

Cuando (no) usar ficheros .htaccess

+ +

Generalmente, solo debería usar ficheros .htaccess cuando no + tiene acceso al fichero principal de configuración del servidor. Hay, por + ejemplo, una creencia errónea de que la autenticación de usuario debería + hacerse siempre dentro de ficheros .htaccess, y, más recientemente, otra creencia errónea de que las directivas de + mod_rewrite deben ir en ficheros .htaccess. + Esto sencillamente no es el caso. Puede poner las configuraciones de + autenticación de usuario en la configuración principal del servidor, y esto + es de hecho, el método preferido de configurar Apache. Del mismo modo, las + directivas mod_rewrite funcionan mejor, en muchos sentidos, en + el fichero de configuración principal del servidor.

+ +

Los ficheros .htaccess deberían usarse cuando su proveedor + de contenidos le permite hacer modificaciones de configuración + en contexto directorio, pero usted no tiene acceso de root en el servidor. + En el caso de que el administrador no esté dispuesto a hacer cambios + frecuentes en la configuración, puede que sea necesario permitir a usuarios + individuales realizar estos cambios de configuración en ficheros + .htaccess por ellos mismos. Lo cual ocurre a menudo, por + ejemplo, en casos donde los ISP están albergando múltiples sitios web de + usuario en una sola máquina, y quieren que sus usuarios tengan la + posibilidad de modificar sus configuraciones.

+ +

Aun así, generalmente, el uso de ficheros .htaccess debería + evitarse cuando sea posible. Cualquier configuración que consideraría poner + en un fichero .htaccess, puede usarse con la misma efectividad + en una sección <Directory> en el fichero de configuración + del servidor.

+ +

Hay dos razones para evitar el uso de ficheros .htaccess.

+ +

La primera es el rendimiento. Cuando AllowOverride + está configurado para permitir el uso de ficheros .htaccess, + httpd buscará ficheros .htaccess en cada directorio. Así, + permitiendo ficheros .htaccess provoca una pérdida de + rendimiento, ¡incluso aunque no los use! Además, los ficheros + .htaccess se cargan cada vez que se solicita un documento.

+ +

Además tenga en cuenta que httpd debe buscar ficheros + .htaccess en todos los directorios de mayor jerarquía, + para poder terner la lista completa de directivas que debe aplicar. (Vea + la sección sobre Cómo se aplican las directivas.) Así, si + se solicita un fichero de un directorio /www/htdocs/example, + httpd debe buscar los siguientes ficheros:

+ +

+ /.htaccess + /www/.htaccess + /www/htdocs/.htaccess + /www/htdocs/example/.htaccess +

+ +

De esta manera, por cada acceso a un fichero de ese directorio, hay 4 + accesos adicionales al sistema de ficheros, incluso si ninguno de esos + ficheros está presente. (Tenga en cuenta que este caso solo se daría si los + ficheros .htaccess están activados en /, que + generalmente no es el caso.).

+ +

En el caso de las directivas RewriteRule, en el contexto de + .htaccess estas expresiones regulares deben recompilarse con + cada solicitud a ese directorio, cuando en el contexto de configuración del + servidor solo se compilan una vez y se cachean. Adicionalmente, las reglas + en sí mismas son más complicadas, puesto que uno debe sortear las + restricciones que vienen acompañadas del contexto directorio y + mod_rewrite. Consulte la Guía de Rewrite para un mayor + detalle sobre este tema.

+ +

La segunda consideración es de seguridad. Estará permitiendo que usuarios + modifiquen la configuración del servidor, lo cual puede dar lugar a cambios sobre los que usted no tendrá ningún control. Medite profundamente si debe + dar a sus usuarios ese privilegio. Además tenga en cuenta que dar a los usuarios menos privilegios de los que necesitan dará lugar a más peticiones + de soporte. Asegúrese de que le indica a sus usuarios claramente el nivel de privilegios que les está dando. Especificando exactamente cómo ha + configurado AllowOverride, e invíteles + a revisar la documentación relacionada, lo cual le ahorrará + bastantes confusiones más adelante.

+ +

Tenga en cuenta que esto es equivalente por completo a poner un fichero + .htaccess en un directorio /www/htdocs/example + con una directiva, y poner la misma directiva en una sección + Directory <Directory "/www/htdocs/example"> en su + configuración principal del servidor:

+ +

Fichero .htaccess en /www/htdocs/example:

+ +

Contenido de fichero .htaccess en + `/www/htdocs/example`

AddType text/example ".exm"

+ +

Sección de su fichero `httpd.conf`

<Directory "/www/htdocs/example">
+    AddType text/example ".exm"
+</Directory>

+ +

Aun así, poniendo ésta en el fichero de configuración dará como resultado + una menor pérdida de rendimiento, y como la configuración se carga una vez + cuando el httpd arranca, en lugar de cada vez que se solicita un fichero.

+ +

El uso de ficheros .htaccess puede desactivarse por completo + configurando la directiva AllowOverride + a none:

+ +

AllowOverride None

+ +

How directives are applied

+ +

Las directivas de configuración que se encuentran en el fichero + .htaccess se aplican al directorio en el que el fichero + .htaccess se encuentra, y a todos sus subdirectorios. Sin + embargo, es importante recordar que puede haber otros ficheros + .htaccess en directorios previos. Las directivas se aplican en + el orden en el que se encuentran. Por lo tanto, un fichero + .htaccess puede sobrescribir directivas que se encuentran + en ficheros .htaccess que se encuentran en directorios previos + del árbol de directorios. Y estos, en cambio, pueden haber sobrescrito + directivas que se encontraban más arriba, o en el fichero principal de + configuración del servidor mismo.

+ +

Ejemplo:

+ +

En el directorio /www/htdocs/example1 tenemos un fichero + .htaccess que contiene lo siguiente:

+ +

Options +ExecCGI

+ + +

(Nota: debe terner "AllowOverride Options" configurado para + permitir el uso de la directiva "Options" en ficheros + .htaccess files.)

+ +

En el directorio /www/htdocs/example1/example2 tenemos un + fichero .htaccess que contiene:

+ +

Options Includes

+ + +

Por este segundo fichero .htaccess, en el directorio + /www/htdocs/example1/example2, la ejecución de CGI execution no + está permitida, porque solo se ha definido Options Includes, + que sobrescribe completamente una configuración previa que se pudiera haber + definido.

+ +

Incorporando el .htaccess en los ficheros de + configuración principal

+ +

Como se ha comentado en la documentación en las Secciones de Configuración, los ficheros + .htaccess pueden sobrescribir las secciones <Directory> por el directorio + correspondiente, pero se sobrescribirán por otros tipos de secciones de + configuración de los ficheros de configuración principal. Este hecho se + puede usar para forzar ciertas configuraciones, incluso en presencia + de una configuración laxa de + AllowOverride. Por ejemplo, para + prevenir la ejecución de un script mientras se permite cualquier otra cosa + en .htaccess puede usar:

+ +

<Directory "/www/htdocs">
+    AllowOverride All
+</Directory>
+
+<Location "/">
+    Options +IncludesNoExec -ExecCGI
+</Location>

+ + +

Este ejemplo asume que su DocumentRoot es /www/htdocs.

+ + +

Ejemplo de Autenticación

+ +

Si saltó directamente a esta parte del documento para averiguar como + hacer la autenticación, es important que tenga en cuenta una cosa. Hay una + creencia errónea de que necesita usar ficheros .htaccess para + configurar autenticación con contraseña. Este no es el caso. Colocar las + directivas de autenticación en una sección + <Directory>, en su fichero + de configuración principal, es el método recomendado para configurar esto, + y los ficheros .htaccess deberían usarse solamente si no tiene + acceso al fichero de configuración principal del servidor. Vea más arriba una explicación de cuando debería y cuando no + debería usar ficheros .htaccess.

+ +

Dicho esto, si todavía cree que debe usar el fichero + .htaccess, podrá ver que una configuración como la que sigue + podría servirle.

+ +

Contenido del fichero .htaccess:

+ +

AuthType Basic
+AuthName "Password Required"
+AuthUserFile "/www/passwords/password.file"
+AuthGroupFile "/www/passwords/group.file"
+Require group admins

+ + +

Tenga en cuenta que AllowOverride AuthConfig debe estar + habilitado para que estas directivas tengan algún efecto.

+ +

Por favor vea el tutorial de autenticación para + una explicación más completa de la autenticación y la autorización.

Ejemplo de Server Side Includes

+ +

Otro uso común de ficheros .htaccess es activar Server Side + Includes para un directorio en particular. Esto puede hacerse + con las siguientes directivas de configuración, colocadas en un fichero + .htaccess y el directorio deseado:

+ +

Options +Includes
+AddType text/html "shtml"
+AddHandler server-parsed shtml

+ + +

Tenga en cuenta que AllowOverride Options y + AllowOverride FileInfo deben estar activadas para que estas + directivas tengan efecto.

+ +

Por favor vea el tutorial de SSI para una + explicación más completa de server-side includes.

Reglas de Rewrite en ficheros .htaccess

Cuando use RewriteRule en + ficheros .htaccess, tenga en cuenta que el contexto + directorio cambia las cosas un poco. En concreto, las reglas son + relativas al directorio actual, en lugar de serlo de la petición de URI + solicitada originalmente. + Considere los siguientes ejemplos:

+ +

# En httpd.conf
+RewriteRule "^/images/(.+)\.jpg" "/images/$1.png"
+
+# En .htaccess en el directorio raíz
+RewriteRule "^images/(.+)\.jpg" "images/$1.png"
+
+# En .htaccess en images/
+RewriteRule "^(.+)\.jpg" "$1.png"

+ + +

En un .htaccess en cualquier directorio del DocumentRoot, la + barra ("/") inicial se elimina del valor facilitado a RewriteRule, y en el subdirectorio + images, se elimina /images/ también de este valor. + Así, su expresión regular necesita omitir también esa parte.

+ +

Consulte la documentación de mod_rewrite para + más detalles al usar mod_rewrite.

+ +

Ejemplo de CGI

+ +

Finalmente, puede que quiera usar un fichero .htaccess para + permitir la ejecución de programas CGI en un directorio en particular. Esto + se puede implementar con la siguiente configuración:

+ +

Options +ExecCGI
+AddHandler cgi-script "cgi" "pl"

+ + +

Alternativamente, si quiere considerar como programas CGI todos los + ficheros de un directorio concreto, esto se puede conseguir con la siguiente + configuración:

+ +

Options +ExecCGI
+SetHandler cgi-script

+ + +

Tenga en cuenta que AllowOverride Options y + AllowOverride FileInfo deben estar ambas activadas para que + estas directivas tengan efecto.

+ +

Por favor vea el tutorial CGI para mayor detalle + sobre programación y configuración de CGI.

+ +

Resolución de problemas

+ +

Cuando pone directivas en un fichero .htaccess y no obtiene + el efecto deseado hay una serie de cosas que pueden haber ido mal.

+ +

El problema más común es que AllowOverride + no está configurada para que sus directivas puedan surtir + efecto. Asegúrese de que no tiene AllowOverride None + configurado para el directorio en cuestión. Una buena forma de probar esto + es poner "basura" en su fichero .htaccess y recargar la página. + Si no se genera un error en el servidor, casi seguro que tiene configurado + AllowOverride None.

+ +

Si, por otro lado, obtiene errores de servidor al intentar acceder a + documentos, compruebe el log de errores de httpd. Seguramente le indiquen + que la directiva en uso en su fichero .htaccess no está + permitida.

+ +

+ [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here +

+ +

Esto indicará que o bien ha usado una directiva que no se permite nunca + en ficheros .htaccess, o que simplementa no tiene + AllowOverride configurado + a un nivel suficiente para la directiva que ha usado. Consulte la + documentación para esa directiva en particular para determinar cual es el + caso.

+ +

Alternativamente, puede que le indique que hay un error de sintaxis en + el uso de la propia directiva.

+ +

+ [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters +

+ +

En este caso, el mensaje de error debería ser específico para el error de + sintaxis concreto que ha cometido.

+ +

Idiomas disponibles: en | + es | + fr | + ja | + ko | + pt-br

Comentarios

+ \ No newline at end of file diff --git a/docs/manual/howto/htaccess.xml.es b/docs/manual/howto/htaccess.xml.es new file mode 100644 index 0000000000..0e25a9525b --- /dev/null +++ b/docs/manual/howto/htaccess.xml.es @@ -0,0 +1,475 @@ + + + + + + + + + +How-To / Tutoriales + +Tutorial del Servidor Apache HTTP: Ficheros .htaccess + +

Los ficheros .htaccess facilitan una forma de realizar + cambios en la configuraciÃ³n en contexto directorio.

+ + + +

+QuÃ© son/CÃ³mo usarlos + +

Los ficheros .htaccess (o "ficheros de configuraciÃ³n + distribuida") facilitan una forma de realizar cambios en la configuraciÃ³n + en contexto directorio. Un fichero, que contiene una o mÃ¡s directivas, se + coloca en un documento especÃfico de un directorio, y estas directivas + aplican a ese directorio y todos sus subdirectorios.

+ + Nota: +

Si quiere llamar a su fichero .htaccess de otra manera, + puede cambiar el nombre del fichero usando la directiva AccessFileName. Por ejemplo, si usted prefiere + llamar al fichero .config, entonces puede poner lo siguiente + en el fichero de configuraciÃ³n de su servidor:

+ + +AccessFileName ".config" + + + +

Generalmente, los ficheros .htaccess usan la misma sintÃ¡xis + que los ficheros de la configuraciÃ³n + principal. Lo que puede utilizar en estos ficheros lo determina la + directiva AllowOverride. Esta directiva + especifica, en categorÃas, quÃ© directivas tendrÃ¡n efecto si se encuentran en + un fichero .htaccess. Si se permite una directiva en un fichero + .htaccess, la documentaciÃ³n para esa directiva contendrÃ¡ una + secciÃ³n Override, especificando quÃ© valor debe ir en + AllowOverride para que se permita esa + directiva.

+ +

Por ejemplo, si busca en la documentaciÃ³n la directiva AddDefaultCharset, encontrarÃ¡ que se permite en + ficheros .htaccess. (Vea la lÃnea de Contexto en el sumario de + la directiva.) La lÃnea Override muestra + FileInfo. De este modo, debe tener al menos + AllowOverride FileInfo para que esta directiva se aplique en + ficheros .htaccess.

+ + Ejemplo: + + + + + + + + + + +

Context:	server config, virtual host, directory, .htaccess
Override:	FileInfo

+ + +

Si no estÃ¡ seguro de cuÃ¡ndo, una directiva en concreto, se puede usar en un + fichero .htaccess, consulte la documentaciÃ³n para esa directiva, + y compruebe la lÃnea Context buscando ".htaccess".

+ +

Cuando (no) usar ficheros .htaccess + +

Generalmente, solo deberÃa usar ficheros .htaccess cuando no + tiene acceso al fichero principal de configuraciÃ³n del servidor. Hay, por + ejemplo, una creencia errÃ³nea de que la autenticaciÃ³n de usuario deberÃa + hacerse siempre dentro de ficheros .htaccess, y, mÃ¡s recientemente, otra creencia errÃ³nea de que las directivas de + mod_rewrite deben ir en ficheros .htaccess. + Esto sencillamente no es el caso. Puede poner las configuraciones de + autenticaciÃ³n de usuario en la configuraciÃ³n principal del servidor, y esto + es de hecho, el mÃ©todo preferido de configurar Apache. Del mismo modo, las + directivas mod_rewrite funcionan mejor, en muchos sentidos, en + el fichero de configuraciÃ³n principal del servidor.

+ +

Los ficheros .htaccess deberÃan usarse cuando su proveedor + de contenidos le permite hacer modificaciones de configuraciÃ³n + en contexto directorio, pero usted no tiene acceso de root en el servidor. + En el caso de que el administrador no estÃ© dispuesto a hacer cambios + frecuentes en la configuraciÃ³n, puede que sea necesario permitir a usuarios + individuales realizar estos cambios de configuraciÃ³n en ficheros + .htaccess por ellos mismos. Lo cual ocurre a menudo, por + ejemplo, en casos donde los ISP estÃ¡n albergando mÃºltiples sitios web de + usuario en una sola mÃ¡quina, y quieren que sus usuarios tengan la + posibilidad de modificar sus configuraciones.

+ +

Aun asÃ, generalmente, el uso de ficheros .htaccess deberÃa + evitarse cuando sea posible. Cualquier configuraciÃ³n que considerarÃa poner + en un fichero .htaccess, puede usarse con la misma efectividad + en una secciÃ³n Directory en el fichero de configuraciÃ³n + del servidor.

+ +

Hay dos razones para evitar el uso de ficheros .htaccess.

+ +

La primera es el rendimiento. Cuando AllowOverride + estÃ¡ configurado para permitir el uso de ficheros .htaccess, + httpd buscarÃ¡ ficheros .htaccess en cada directorio. AsÃ, + permitiendo ficheros .htaccess provoca una pÃ©rdida de + rendimiento, Â¡incluso aunque no los use! AdemÃ¡s, los ficheros + .htaccess se cargan cada vez que se solicita un documento.

+ +

AdemÃ¡s tenga en cuenta que httpd debe buscar ficheros + .htaccess en todos los directorios de mayor jerarquÃa, + para poder terner la lista completa de directivas que debe aplicar. (Vea + la secciÃ³n sobre CÃ³mo se aplican las directivas.) AsÃ, si + se solicita un fichero de un directorio /www/htdocs/example, + httpd debe buscar los siguientes ficheros:

+ + + /.htaccess
+ /www/.htaccess
+ /www/htdocs/.htaccess
+ /www/htdocs/example/.htaccess + + +

De esta manera, por cada acceso a un fichero de ese directorio, hay 4 + accesos adicionales al sistema de ficheros, incluso si ninguno de esos + ficheros estÃ¡ presente. (Tenga en cuenta que este caso solo se darÃa si los + ficheros .htaccess estÃ¡n activados en /, que + generalmente no es el caso.).

+ +

En el caso de las directivas RewriteRule, en el contexto de + .htaccess estas expresiones regulares deben recompilarse con + cada solicitud a ese directorio, cuando en el contexto de configuraciÃ³n del + servidor solo se compilan una vez y se cachean. Adicionalmente, las reglas + en sÃ mismas son mÃ¡s complicadas, puesto que uno debe sortear las + restricciones que vienen acompaÃ±adas del contexto directorio y + mod_rewrite. Consulte la GuÃa de Rewrite para un mayor + detalle sobre este tema.

+ +

La segunda consideraciÃ³n es de seguridad. EstarÃ¡ permitiendo que usuarios + modifiquen la configuraciÃ³n del servidor, lo cual puede dar lugar a cambios sobre los que usted no tendrÃ¡ ningÃºn control. Medite profundamente si debe + dar a sus usuarios ese privilegio. AdemÃ¡s tenga en cuenta que dar a los usuarios menos privilegios de los que necesitan darÃ¡ lugar a mÃ¡s peticiones + de soporte. AsegÃºrese de que le indica a sus usuarios claramente el nivel de privilegios que les estÃ¡ dando. Especificando exactamente cÃ³mo ha + configurado AllowOverride, e invÃteles + a revisar la documentaciÃ³n relacionada, lo cual le ahorrarÃ¡ + bastantes confusiones mÃ¡s adelante.

+ +

Tenga en cuenta que esto es equivalente por completo a poner un fichero + .htaccess en un directorio /www/htdocs/example + con una directiva, y poner la misma directiva en una secciÃ³n + Directory <Directory "/www/htdocs/example"> en su + configuraciÃ³n principal del servidor:

+ +

Fichero .htaccess en /www/htdocs/example:

+ + Contenido de fichero .htaccess en + <code>/www/htdocs/example</code> + +AddType text/example ".exm" + + + + SecciÃ³n de su fichero <code>httpd.conf</code> + +<Directory "/www/htdocs/example"> + AddType text/example ".exm" +</Directory> + + + +

Aun asÃ, poniendo Ã©sta en el fichero de configuraciÃ³n darÃ¡ como resultado + una menor pÃ©rdida de rendimiento, y como la configuraciÃ³n se carga una vez + cuando el httpd arranca, en lugar de cada vez que se solicita un fichero.

+ +

El uso de ficheros .htaccess puede desactivarse por completo + configurando la directiva AllowOverride + a none:

+ + +AllowOverride None + +

+ +

How directives are applied + +

Las directivas de configuraciÃ³n que se encuentran en el fichero + .htaccess se aplican al directorio en el que el fichero + .htaccess se encuentra, y a todos sus subdirectorios. Sin + embargo, es importante recordar que puede haber otros ficheros + .htaccess en directorios previos. Las directivas se aplican en + el orden en el que se encuentran. Por lo tanto, un fichero + .htaccess puede sobrescribir directivas que se encuentran + en ficheros .htaccess que se encuentran en directorios previos + del Ã¡rbol de directorios. Y estos, en cambio, pueden haber sobrescrito + directivas que se encontraban mÃ¡s arriba, o en el fichero principal de + configuraciÃ³n del servidor mismo.

+ +

Ejemplo:

+ +

En el directorio /www/htdocs/example1 tenemos un fichero + .htaccess que contiene lo siguiente:

+ + +Options +ExecCGI + + +

(Nota: debe terner "AllowOverride Options" configurado para + permitir el uso de la directiva "Options" en ficheros + .htaccess files.)

+ +

En el directorio /www/htdocs/example1/example2 tenemos un + fichero .htaccess que contiene:

+ + +Options Includes + + +

Por este segundo fichero .htaccess, en el directorio + /www/htdocs/example1/example2, la ejecuciÃ³n de CGI execution no + estÃ¡ permitida, porque solo se ha definido Options Includes, + que sobrescribe completamente una configuraciÃ³n previa que se pudiera haber + definido.

+ +

Incorporando el .htaccess en los ficheros de + configuraciÃ³n principal + +

Como se ha comentado en la documentaciÃ³n en las Secciones de ConfiguraciÃ³n, los ficheros + .htaccess pueden sobrescribir las secciones Directory por el directorio + correspondiente, pero se sobrescribirÃ¡n por otros tipos de secciones de + configuraciÃ³n de los ficheros de configuraciÃ³n principal. Este hecho se + puede usar para forzar ciertas configuraciones, incluso en presencia + de una configuraciÃ³n laxa de + AllowOverride. Por ejemplo, para + prevenir la ejecuciÃ³n de un script mientras se permite cualquier otra cosa + en .htaccess puede usar:

+ + +<Directory "/www/htdocs"> + AllowOverride All +</Directory> + +<Location "/"> + Options +IncludesNoExec -ExecCGI +</Location> + + + Este ejemplo asume que su DocumentRoot es /www/htdocs. +

+ +

Ejemplo de AutenticaciÃ³n + +

Si saltÃ³ directamente a esta parte del documento para averiguar como + hacer la autenticaciÃ³n, es important que tenga en cuenta una cosa. Hay una + creencia errÃ³nea de que necesita usar ficheros .htaccess para + configurar autenticaciÃ³n con contraseÃ±a. Este no es el caso. Colocar las + directivas de autenticaciÃ³n en una secciÃ³n + Directory, en su fichero + de configuraciÃ³n principal, es el mÃ©todo recomendado para configurar esto, + y los ficheros .htaccess deberÃan usarse solamente si no tiene + acceso al fichero de configuraciÃ³n principal del servidor. Vea mÃ¡s arriba una explicaciÃ³n de cuando deberÃa y cuando no + deberÃa usar ficheros .htaccess.

+ +

Dicho esto, si todavÃa cree que debe usar el fichero + .htaccess, podrÃ¡ ver que una configuraciÃ³n como la que sigue + podrÃa servirle.

+ +

Contenido del fichero .htaccess:

+ + +AuthType Basic +AuthName "Password Required" +AuthUserFile "/www/passwords/password.file" +AuthGroupFile "/www/passwords/group.file" +Require group admins + + +

Tenga en cuenta que AllowOverride AuthConfig debe estar + habilitado para que estas directivas tengan algÃºn efecto.

+ +

Por favor vea el tutorial de autenticaciÃ³n para + una explicaciÃ³n mÃ¡s completa de la autenticaciÃ³n y la autorizaciÃ³n.

+ +

Ejemplo de Server Side Includes + +

Otro uso comÃºn de ficheros .htaccess es activar Server Side + Includes para un directorio en particular. Esto puede hacerse + con las siguientes directivas de configuraciÃ³n, colocadas en un fichero + .htaccess y el directorio deseado:

+ + +Options +Includes +AddType text/html "shtml" +AddHandler server-parsed shtml + + +

Tenga en cuenta que AllowOverride Options y + AllowOverride FileInfo deben estar activadas para que estas + directivas tengan efecto.

+ +

Por favor vea el tutorial de SSI para una + explicaciÃ³n mÃ¡s completa de server-side includes.

+ +

Reglas de Rewrite en ficheros .htaccess +

Cuando use RewriteRule en + ficheros .htaccess, tenga en cuenta que el contexto + directorio cambia las cosas un poco. En concreto, las reglas son + relativas al directorio actual, en lugar de serlo de la peticiÃ³n de URI + solicitada originalmente. + Considere los siguientes ejemplos:

+ + +# En httpd.conf +RewriteRule "^/images/(.+)\.jpg" "/images/$1.png" + +# En .htaccess en el directorio raÃz +RewriteRule "^images/(.+)\.jpg" "images/$1.png" + +# En .htaccess en images/ +RewriteRule "^(.+)\.jpg" "$1.png" + + +

En un .htaccess en cualquier directorio del DocumentRoot, la + barra ("/") inicial se elimina del valor facilitado a RewriteRule, y en el subdirectorio + images, se elimina /images/ tambiÃ©n de este valor. + AsÃ, su expresiÃ³n regular necesita omitir tambiÃ©n esa parte.

+ +

Consulte la documentaciÃ³n de mod_rewrite para + mÃ¡s detalles al usar mod_rewrite.

+ +

Ejemplo de CGI + +

Finalmente, puede que quiera usar un fichero .htaccess para + permitir la ejecuciÃ³n de programas CGI en un directorio en particular. Esto + se puede implementar con la siguiente configuraciÃ³n:

+ + +Options +ExecCGI +AddHandler cgi-script "cgi" "pl" + + +

Alternativamente, si quiere considerar como programas CGI todos los + ficheros de un directorio concreto, esto se puede conseguir con la siguiente + configuraciÃ³n:

+ + +Options +ExecCGI +SetHandler cgi-script + + +

Tenga en cuenta que AllowOverride Options y + AllowOverride FileInfo deben estar ambas activadas para que + estas directivas tengan efecto.

+ +

Por favor vea el tutorial CGI para mayor detalle + sobre programaciÃ³n y configuraciÃ³n de CGI.

+ +

ResoluciÃ³n de problemas + +

Cuando pone directivas en un fichero .htaccess y no obtiene + el efecto deseado hay una serie de cosas que pueden haber ido mal.

+ +

El problema mÃ¡s comÃºn es que AllowOverride + no estÃ¡ configurada para que sus directivas puedan surtir + efecto. AsegÃºrese de que no tiene AllowOverride None + configurado para el directorio en cuestiÃ³n. Una buena forma de probar esto + es poner "basura" en su fichero .htaccess y recargar la pÃ¡gina. + Si no se genera un error en el servidor, casi seguro que tiene configurado + AllowOverride None.

+ +

+ + + [Fri Sep 17 18:43:16 2010] [alert] [client 192.168.200.51] /var/www/html/.htaccess: DirectoryIndex not allowed here + + +

Esto indicarÃ¡ que o bien ha usado una directiva que no se permite nunca + en ficheros .htaccess, o que simplementa no tiene + AllowOverride configurado + a un nivel suficiente para la directiva que ha usado. Consulte la + documentaciÃ³n para esa directiva en particular para determinar cual es el + caso.

+ +

Alternativamente, puede que le indique que hay un error de sintaxis en + el uso de la propia directiva.

+ + + [Sat Aug 09 16:22:34 2008] [alert] [client 192.168.200.51] /var/www/html/.htaccess: RewriteCond: bad flag delimiters + + +

En este caso, el mensaje de error deberÃa ser especÃfico para el error de + sintaxis concreto que ha cometido.

+ +

+ + diff --git a/docs/manual/howto/htaccess.xml.meta b/docs/manual/howto/htaccess.xml.meta index a962e7243c..f230926987 100644 --- a/docs/manual/howto/htaccess.xml.meta +++ b/docs/manual/howto/htaccess.xml.meta @@ -8,6 +8,7 @@ en + es fr ja ko diff --git a/docs/manual/howto/http2.html.es b/docs/manual/howto/http2.html.es new file mode 100644 index 0000000000..c85ca8e28c --- /dev/null +++ b/docs/manual/howto/http2.html.es @@ -0,0 +1,283 @@ + + + + + +Guía HTTP/2 - Servidor Apache HTTP Versión 2.4 + + + + + + + +

+Apache > Servidor HTTP > Documentación > Versión 2.4 > How-To / Tutoriales

Guía HTTP/2

Idiomas disponibles: en | + es | + fr

+ +

Esta es la guía para configurar HTTP/2 en Apache httpd. Ésta + característica es experimental así que es de esperar que algunas + directivas e interfaces cambien con nuevas versiones. +

El protocolo HTTP/2
HTTP/2 en Apache httpd
Compilar httpd con soporte HTTP/2
Configuración básica
Configuración MPM
Clientes
Herramientas útiles para depurar HTTP/2
Server Push

Consulte también

El protocolo HTTP/2

+ + +

HTTP/2 es la evolución del protocolo de la capa de aplicación con más + éxito, HTTP. Se centra en hacer un uso más eficiente de los recursos de red. No cambia la característica fundamental de HTTP, la semántica. Todavía hay solicitudes, respuestas, cabeceras y todo los elementos típicos de HTTP/1. Así que, si ya conoce HTTP/1, también conoce el 95% de HTTP/2.

+ +

Se ha escrito mucho sobre HTTP/2 y de cómo funciona. La norma más + estándar es, por supuesto, su + RFC 7540 + ( también disponible en un + formato más legible, YMMV). Así que, ahí encontrará toda la especificación del protocolo.

+ +

Pero, como con todos los RFC, no es ideal como primera lectura. Es mejor + entender primero qué se quiere hacer y después leer el RFC sobre + cómo hacerlo. Un documento mucho mejor con el que empezar es + http2 explicado + por Daniel Stenberg, el autor de curl. + ¡También está disponible cada vez en un mayor número lenguajes!

+ +

Si le parece demasiado largo, o no lo ha leido, hay algunos términos + y elementos a tener en cuenta cuando lea este documento:

HTTP/2 es un protocolo binario, al contrario que HTTP 1.1 que es texto plano. La intención para HTTP 1.1 es que sea legible (por ejemplo capturando el tráfico de red) mientras que para HTTP/2 no. Más información en el FAQ oficial ¿Por qué es binario HTTP/2?
h2 es HTTP/2 sobre TLS (negociación de protocolo a través de ALPN).
h2c es HTTP/2 sobre TCP.
Un frame es la unidad más pequeña de comunicación dentro de una conexión HTTP/2, que consiste en una cabecera y una secuencia de octetos de longitud variable estructurada de acuerdo con el tipo de frame. Más información en la documentación oficial Sección de Capa de Frame.
Un stream es un flujo bidireccional de frames dentro de una conexión HTTP/2. El concepto correspondiente en HTTP 1.1 es un intercambio de mensajes de solicitud/respuesta. Más información en la documentación oficial Sección Capa de Stream.
HTTP/2 es capaz de llevar múltiples streams de datos sobre la misma conexión TCP, evitando la clásica solicitud lenta "head-of-line blocking" de HTTP 1.1 y evitando generar múltiples conexiones TCP para cada solicitud/respuesta (KeepAlive parcheó el problema en HTTP 1.1 pero no lo resolvió completamente).

HTTP/2 en Apache httpd

+ +

El protocolo HTTP/2 se implementa con su propio módulo httpd, llamado acertadamente mod_http2. Incluye el set completo de características descritas por el RFC 7540 y soporta HTTP/2 sobre texto plano (http:), así como conexiones seguras (https:). La variante de texto plano se llama 'h2c', la segura 'h2'. Para h2c permite el modo direct + y el Upgrade: a través de una solicitud inicial HTTP/1.

+ +

Una característica de HTTP/2 que ofrece capacidades nuevas para desarrolladores de web es Server Push. Vea esa sección para saber como su aplicación web puede hacer uso de ella.

Compilar httpd con soporte HTTP/2

+ +

mod_http2 usa la librería nghttp2 + como su implementación base. Para compilar mod_http2 necesita al menos la versión 1.2.1 de libnghttp2 instalada en su sistema.

+ +

Cuando usted ejecuta ./configure en el código fuente de Apache HTTPD, necesita indicarle '--enable-http2' como una opción adicional para activar la compilación de este módulo. Si su libnghttp2 está ubicado en una ruta no habitual (cualquiera que sea en su sistema operativo), puede indicar su ubicación con '--with-nghttp2=<path>' para ./configure.

+ +

Aunque puede que eso sirva para la mayoría, habrá quien prefiera un nghttp2 compilado estáticamente para este módulo. Para ellos existe la opción --enable-nghttp2-staticlib-deps. Funciona de manera muy similar a como uno debe enlazar openssl estáticamente para mod_ssl.

+ +

Hablando de SSL, necesita estar al tanto de que la mayoría de los navegadores hablan HTTP/2 solo con URLs https:. Así que necesita un servidor con soporte SSL. Pero no solo eso, necesitará una librería SSL que de soporte a la extensión ALPN. Si usa OpenSSL, necesita al menos la versión 1.0.2.

Configuración básica

+ + +

Cuando tiene un httpd compilado con mod_http2 necesita una configuración básica para activarlo. Lo primero, como con cualquier otro módulo de Apache, es que necesita cargarlo:

+ +

LoadModule http2_module modules/mod_http2.so

+ + +

La segunda directiva que necesita añadir a la configuración de su servidor es:

+ +

Protocols h2 http/1.1

+ + +

Esto permite h2, la variante segura, para ser el protocolo preferido de las conexiones en su servidor. Cuando quiera habilitar todas las variantes de HTTP/2, entonces simplemente configure:

+ +

Protocols h2 h2c http/1.1

+ + +

Dependiendo de dónde pone esta directiva, afecta a todas las conexiones o solo a las de ciertos host virtuales. La puede anidar, como en:

+ +

Protocols http/1.1
+<VirtualHost ...>
+    ServerName test.example.org
+    Protocols h2 http/1.1
+</VirtualHost>

+ + +

Esto solo permite HTTP/1, excepto conexiones SSL hacia test.example.org que ofrecen HTTP/2.

+ +

Escoger un SSLCipherSuite seguro

Es necesario configurar SSLCipherSuite con una suite segura de cifrado TLS. La versión actual de mod_http2 no fuerza ningún cifrado pero la mayoría de los clientes si lo hacen. Encaminar un navegador hacia un servidor con h2 activado con una suite inapropiada de cifrados forzará al navegador a rehusar e intentar conectar por HTTP 1.1. Esto es un error común cuando se configura httpd con HTTP/2 por primera vez, ¡así que por favor tenga en cuenta que debe evitar largas sesiones de depuración! Si quiere estar seguro de la suite de cifrados que escoja, por favor evite los listados en la Lista Negra de TLS para HTTP/2.

+ +

El orden de los protocolos mencionados también es relevante. Por defecto, el primero es el protocolo preferido. Cuando un cliente ofrece múltiples opciones, la que esté más a la izquierda será la escogida. En

Protocols http/1.1 h2

+ + +

el protocolo preferido es HTTP/1 y siempre será seleccionado a menos que el cliente sólo soporte h2. Puesto que queremos hablar HTTP/2 con clientes que lo soporten, el orden correcto es:

+ +

Protocols h2 h2c http/1.1

+ + +

Hay algo más respecto al orden: el cliente también tiene sus propias preferencias. Si quiere, puede configurar su servidor para seleccionar el protocolo preferido por el cliente:

+ +

ProtocolsHonorOrder Off

+ + +

Hace que el orden en que usted escribió los Protocols sea irrelevante y sólo el orden de preferencia del cliente será decisorio.

+ +

Una última cosa: cuando usted configura los protocolos no se comprueba si son correctos o están bien escritos. Puede mencionar protocolos que no existen, así que no hay necesidad de proteger Protocols con ningún IfModule de comprobación.

+ +

Para más consejos avanzados de configuración, vea la + sección de módulos sobre dimensionamiento y + como gestionar multiples hosts con el mismo certificado.

Configuración MPM

+ + +

HTTP/2 está soportado en todos los módulos de multi-proceso que se ofrecen con httpd. Aun así, si usa el mpm prefork, habrá restricciones severas.

+ +

En prefork, mod_http2 solo procesará una solicitud cada vez por conexión. Pero los clientes, como los navegadores, enviarán muchas solicitudes al mismo tiempo. Si una de ellas tarda mucho en procesarse (o hace un sondeo que dura más de la cuenta), las otras solicitudes se quedarán atascadas.

+ +

mod_http2 no evitará este límite por defecto. El motivo es que prefork hoy en día solo se escoge si ejecuta motores de proceso que no están preparados para multi-hilo, p.ej. fallará con más de una solicitud.

+ +

Si su configuración lo soporta, hoy en día event es el mejor mpm que puede usar.

+ +

Si realmente está obligado a usar prefork y quiere multiples solicitudes, puede configurar la directiva H2MinWorkers para hacerlo posible. Sin embargo, si esto falla, es bajo su cuenta y riesgo.

Clientes

+ + +

Casi todos los navegadores modernos dan soporte a HTTP/2, pero solo en conexiones SSL: Firefox (v43), Chrome (v45), Safari (since v9), iOS Safari (v9), Opera (v35), Chrome para Android (v49) e Internet Explorer (v11 en Windows10) (Fuente).

+ +

Otros clientes, así cómo otros servidores, están listados en la + wiki de Implementaciones, entre ellos, implementaciones para c, c++, common lisp, dart, erlang, haskell, java, nodejs, php, python, perl, ruby, rust, scala y swift.

+ +

Muchos de las implementaciones de clientes que no son navegadores soportan HTTP/2 sobre texto plano, h2c. La más versátil es curl.

Herramientas útiles para depurar HTTP/2

+ + +

La primera herramienta a mencionar es por supuesto curl. Por favor asegúrese de que su versión soporta HTTP/2 comprobando sus Características:

    $ curl -V
+    curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4
+    Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...] 
+    Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2
+

+ +

Notas sobre Mac OS homebrew

+ brew install curl --with-openssl --with-nghttp2 +

Y para una inspección en gran profundidad wireshark.

El paquete nghttp2 también incluye clientes, tales como:

nghttp + - util para visualizar la frames de HTTP/2 y tener una mejor idea de como funciona el protocolo.
h2load - útil para hacer un stress-test de su servidor.

+ +

Chrome ofrece logs detallados de HTTP/2 en sus conexiones a través de la página especial de net-internals. También hay una extensión interesante para Chrome y Firefox con la que visualizar cuando su navegador usa HTTP/2.

Server Push

+ + +

El protocolo HTTP/2 permite al servidor hacer PUSH de respuestas a un cliente que nunca las solicitó. El tono de la conversación es: "Aquí tiene una solicitud que nunca envió y la respuesta llegará pronto..."

+ +

Pero hay restricciones: el cliente puede deshabilitar esta característica y el servidor entonces solo podrá hacer PUSH en una solicitud que hizo previamente del cliente.

+ +

La intención es permitir al servidor enviar recursos que el cliente seguramente vaya a necesitar, p. ej. un recurso css o javascript que pertenece a una página html que el cliente solicitó, un grupo de imágenes a las que se hace referencia en un css, etc.

+ +

La ventaja para el cliente es que ahorra tiempo para solicitudes que pueden tardar desde unos pocos milisegundos a medio segundo, dependiendo de la distancia entre el cliente y el servidor. La desventaja es que el cliente puede recibir cosas que ya tiene en su cache. Por supuesto que HTTP/2 soporta cancelación previa de tales solicitudes, pero aun así se malgastan recursos.

+ +

Resumiendo: no hay una estrategia mejor sobre cómo usar esta característica de HTTP/2 y todo el mundo está experimentando con ella. Así que, ¿cómo experimenta usted con ella en Apache httpd?

+ +

mod_http2 busca e inspecciona las cabeceras de respuesta + Link con cierto formato:

+ +

Link </xxx.css>;rel=preload, </xxx.js>; rel=preload

+ + +

Si la conexión soporta PUSH, estos dos recursos se enviarán al cliente. Como desarrollador web, puede configurar estas cabeceras o bien directamente en la respuesta de su aplicación o configurar su servidor con:

+ +

<Location /xxx.html>
+    Header add Link "</xxx.css>;rel=preload"
+    Header add Link "</xxx.js>;rel=preload"
+</Location>

+ + +

Si quiere usar enlaces con preload sin activar un PUSH, puede usar el parámetro nopush, como en:

+ +

Link </xxx.css>;rel=preload;nopush

+ + +

o puede desactivar PUSH para su servidor por completo con la directiva

+ +

H2Push Off

+ + +

Y hay más:

+ +

El módulo mantiene un registro de lo que se ha enviado con PUSH para cada conexión (hashes de URLs, básicamente) y no hará PUSH del mismo recurso dos veces. Cuando la conexión se cierra, la información es descartada.

+ +

Hay gente pensando cómo un cliente puede decirle al servidor lo que ya tiene, para evitar los PUSH de esos elementos, pero eso algo muy experimental ahora mismo.

+ +

Otro borrador experimental que ha sido implementado en + mod_http2 es el Campo de Cabecera + Accept-Push-Policy en la que un cliente puede, para cada solicitud, definir qué tipo de PUSH acepta.

Idiomas disponibles: en | + es | + fr

Comentarios

+ \ No newline at end of file diff --git a/docs/manual/howto/http2.xml.es b/docs/manual/howto/http2.xml.es new file mode 100644 index 0000000000..ae56677881 --- /dev/null +++ b/docs/manual/howto/http2.xml.es @@ -0,0 +1,258 @@ + + + + + + + + + + +How-To / Tutoriales + + GuÃa HTTP/2 + +

Esta es la guÃa para configurar HTTP/2 en Apache httpd. Ãsta + caracterÃstica es experimental asÃ que es de esperar que algunas + directivas e interfaces cambien con nuevas versiones. +

+ mod_http2 + +

+ El protocolo HTTP/2 + +

HTTP/2 es la evoluciÃ³n del protocolo de la capa de aplicaciÃ³n con mÃ¡s + Ã©xito, HTTP. Se centra en hacer un uso mÃ¡s eficiente de los recursos de red. No cambia la caracterÃstica fundamental de HTTP, la semÃ¡ntica. TodavÃa hay solicitudes, respuestas, cabeceras y todo los elementos tÃpicos de HTTP/1. AsÃ que, si ya conoce HTTP/1, tambiÃ©n conoce el 95% de HTTP/2.

+ +

Se ha escrito mucho sobre HTTP/2 y de cÃ³mo funciona. La norma mÃ¡s + estÃ¡ndar es, por supuesto, su + RFC 7540 + ( tambiÃ©n disponible en un + formato mÃ¡s legible, YMMV). AsÃ que, ahÃ encontrarÃ¡ toda la especificaciÃ³n del protocolo.

+ +

Pero, como con todos los RFC, no es ideal como primera lectura. Es mejor + entender primero quÃ© se quiere hacer y despuÃ©s leer el RFC sobre + cÃ³mo hacerlo. Un documento mucho mejor con el que empezar es + http2 explicado + por Daniel Stenberg, el autor de curl. + Â¡TambiÃ©n estÃ¡ disponible cada vez en un mayor nÃºmero lenguajes!

+ +

Si le parece demasiado largo, o no lo ha leido, hay algunos tÃ©rminos + y elementos a tener en cuenta cuando lea este documento:

HTTP/2 es un protocolo binario, al contrario que HTTP 1.1 que es texto plano. La intenciÃ³n para HTTP 1.1 es que sea legible (por ejemplo capturando el trÃ¡fico de red) mientras que para HTTP/2 no. MÃ¡s informaciÃ³n en el FAQ oficial Â¿Por quÃ© es binario HTTP/2?
h2c es HTTP/2 sobre TCP.
Un frame es la unidad mÃ¡s pequeÃ±a de comunicaciÃ³n dentro de una conexiÃ³n HTTP/2, que consiste en una cabecera y una secuencia de octetos de longitud variable estructurada de acuerdo con el tipo de frame. MÃ¡s informaciÃ³n en la documentaciÃ³n oficial SecciÃ³n de Capa de Frame.
Un stream es un flujo bidireccional de frames dentro de una conexiÃ³n HTTP/2. El concepto correspondiente en HTTP 1.1 es un intercambio de mensajes de solicitud/respuesta. MÃ¡s informaciÃ³n en la documentaciÃ³n oficial SecciÃ³n Capa de Stream.
HTTP/2 es capaz de llevar mÃºltiples streams de datos sobre la misma conexiÃ³n TCP, evitando la clÃ¡sica solicitud lenta "head-of-line blocking" de HTTP 1.1 y evitando generar mÃºltiples conexiones TCP para cada solicitud/respuesta (KeepAlive parcheÃ³ el problema en HTTP 1.1 pero no lo resolviÃ³ completamente).

+ +

+ HTTP/2 en Apache httpd +

El protocolo HTTP/2 se implementa con su propio mÃ³dulo httpd, llamado acertadamente mod_http2. Incluye el set completo de caracterÃsticas descritas por el RFC 7540 y soporta HTTP/2 sobre texto plano (http:), asÃ como conexiones seguras (https:). La variante de texto plano se llama 'h2c', la segura 'h2'. Para h2c permite el modo direct + y el Upgrade: a travÃ©s de una solicitud inicial HTTP/1.

+ +

Una caracterÃstica de HTTP/2 que ofrece capacidades nuevas para desarrolladores de web es Server Push. Vea esa secciÃ³n para saber como su aplicaciÃ³n web puede hacer uso de ella.

+ +

+ Compilar httpd con soporte HTTP/2 +

mod_http2 usa la librerÃa nghttp2 + como su implementaciÃ³n base. Para compilar mod_http2 necesita al menos la versiÃ³n 1.2.1 de libnghttp2 instalada en su sistema.

+ +

Cuando usted ejecuta ./configure en el cÃ³digo fuente de Apache HTTPD, necesita indicarle '--enable-http2' como una opciÃ³n adicional para activar la compilaciÃ³n de este mÃ³dulo. Si su libnghttp2 estÃ¡ ubicado en una ruta no habitual (cualquiera que sea en su sistema operativo), puede indicar su ubicaciÃ³n con '--with-nghttp2=<path>' para ./configure.

+ +

Aunque puede que eso sirva para la mayorÃa, habrÃ¡ quien prefiera un nghttp2 compilado estÃ¡ticamente para este mÃ³dulo. Para ellos existe la opciÃ³n --enable-nghttp2-staticlib-deps. Funciona de manera muy similar a como uno debe enlazar openssl estÃ¡ticamente para mod_ssl.

+ +

Hablando de SSL, necesita estar al tanto de que la mayorÃa de los navegadores hablan HTTP/2 solo con URLs https:. AsÃ que necesita un servidor con soporte SSL. Pero no solo eso, necesitarÃ¡ una librerÃa SSL que de soporte a la extensiÃ³n ALPN. Si usa OpenSSL, necesita al menos la versiÃ³n 1.0.2.

+ +

+ ConfiguraciÃ³n bÃ¡sica + +

Cuando tiene un httpd compilado con mod_http2 necesita una configuraciÃ³n bÃ¡sica para activarlo. Lo primero, como con cualquier otro mÃ³dulo de Apache, es que necesita cargarlo:

+ + +LoadModule http2_module modules/mod_http2.so + + +

La segunda directiva que necesita aÃ±adir a la configuraciÃ³n de su servidor es:

+ + +Protocols h2 http/1.1 + + +

Esto permite h2, la variante segura, para ser el protocolo preferido de las conexiones en su servidor. Cuando quiera habilitar todas las variantes de HTTP/2, entonces simplemente configure:

+ + +Protocols h2 h2c http/1.1 + + +

Dependiendo de dÃ³nde pone esta directiva, afecta a todas las conexiones o solo a las de ciertos host virtuales. La puede anidar, como en:

+ + +Protocols http/1.1 +<VirtualHost ...> + ServerName test.example.org + Protocols h2 http/1.1 +</VirtualHost> + + +

Esto solo permite HTTP/1, excepto conexiones SSL hacia test.example.org que ofrecen HTTP/2.

+ + Escoger un SSLCipherSuite seguro +

Es necesario configurar SSLCipherSuite con una suite segura de cifrado TLS. La versiÃ³n actual de mod_http2 no fuerza ningÃºn cifrado pero la mayorÃa de los clientes si lo hacen. Encaminar un navegador hacia un servidor con h2 activado con una suite inapropiada de cifrados forzarÃ¡ al navegador a rehusar e intentar conectar por HTTP 1.1. Esto es un error comÃºn cuando se configura httpd con HTTP/2 por primera vez, Â¡asÃ que por favor tenga en cuenta que debe evitar largas sesiones de depuraciÃ³n! Si quiere estar seguro de la suite de cifrados que escoja, por favor evite los listados en la Lista Negra de TLS para HTTP/2.

+ + +

El orden de los protocolos mencionados tambiÃ©n es relevante. Por defecto, el primero es el protocolo preferido. Cuando un cliente ofrece mÃºltiples opciones, la que estÃ© mÃ¡s a la izquierda serÃ¡ la escogida. En

+ +Protocols http/1.1 h2 + + +

el protocolo preferido es HTTP/1 y siempre serÃ¡ seleccionado a menos que el cliente sÃ³lo soporte h2. Puesto que queremos hablar HTTP/2 con clientes que lo soporten, el orden correcto es:

+ + +Protocols h2 h2c http/1.1 + + +

Hay algo mÃ¡s respecto al orden: el cliente tambiÃ©n tiene sus propias preferencias. Si quiere, puede configurar su servidor para seleccionar el protocolo preferido por el cliente:

+ + +ProtocolsHonorOrder Off + + +

Hace que el orden en que usted escribiÃ³ los Protocols sea irrelevante y sÃ³lo el orden de preferencia del cliente serÃ¡ decisorio.

+ +

Una Ãºltima cosa: cuando usted configura los protocolos no se comprueba si son correctos o estÃ¡n bien escritos. Puede mencionar protocolos que no existen, asÃ que no hay necesidad de proteger Protocols con ningÃºn IfModule de comprobaciÃ³n.

+ +

Para mÃ¡s consejos avanzados de configuraciÃ³n, vea la + secciÃ³n de mÃ³dulos sobre dimensionamiento y + como gestionar multiples hosts con el mismo certificado.

+ +

+ ConfiguraciÃ³n MPM + +

HTTP/2 estÃ¡ soportado en todos los mÃ³dulos de multi-proceso que se ofrecen con httpd. Aun asÃ, si usa el mpm prefork, habrÃ¡ restricciones severas.

+ +

En prefork, mod_http2 solo procesarÃ¡ una solicitud cada vez por conexiÃ³n. Pero los clientes, como los navegadores, enviarÃ¡n muchas solicitudes al mismo tiempo. Si una de ellas tarda mucho en procesarse (o hace un sondeo que dura mÃ¡s de la cuenta), las otras solicitudes se quedarÃ¡n atascadas.

+ +

mod_http2 no evitarÃ¡ este lÃmite por defecto. El motivo es que prefork hoy en dÃa solo se escoge si ejecuta motores de proceso que no estÃ¡n preparados para multi-hilo, p.ej. fallarÃ¡ con mÃ¡s de una solicitud.

+ +

Si su configuraciÃ³n lo soporta, hoy en dÃa event es el mejor mpm que puede usar.

+ +

Si realmente estÃ¡ obligado a usar prefork y quiere multiples solicitudes, puede configurar la directiva H2MinWorkers para hacerlo posible. Sin embargo, si esto falla, es bajo su cuenta y riesgo.

+ +

+ Clientes + +

+ +

Otros clientes, asÃ cÃ³mo otros servidores, estÃ¡n listados en la + wiki de Implementaciones, entre ellos, implementaciones para c, c++, common lisp, dart, erlang, haskell, java, nodejs, php, python, perl, ruby, rust, scala y swift.

+ +

Muchos de las implementaciones de clientes que no son navegadores soportan HTTP/2 sobre texto plano, h2c. La mÃ¡s versÃ¡til es curl.

+ +

+ Herramientas Ãºtiles para depurar HTTP/2 + +

La primera herramienta a mencionar es por supuesto curl. Por favor asegÃºrese de que su versiÃ³n soporta HTTP/2 comprobando sus CaracterÃsticas:

+ + $ curl -V + curl 7.45.0 (x86_64-apple-darwin15.0.0) libcurl/7.45.0 OpenSSL/1.0.2d zlib/1.2.8 nghttp2/1.3.4 + Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 [...] + Features: IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP HTTP2 + + Notas sobre Mac OS homebrew + brew install curl --with-openssl --with-nghttp2 + +

Y para una inspecciÃ³n en gran profundidad wireshark.

nghttp + - util para visualizar la frames de HTTP/2 y tener una mejor idea de como funciona el protocolo.
h2load - Ãºtil para hacer un stress-test de su servidor.

+ +

Chrome ofrece logs detallados de HTTP/2 en sus conexiones a travÃ©s de la pÃ¡gina especial de net-internals. TambiÃ©n hay una extensiÃ³n interesante para Chrome y Firefox con la que visualizar cuando su navegador usa HTTP/2.

+ +

+ Server Push + +

El protocolo HTTP/2 permite al servidor hacer PUSH de respuestas a un cliente que nunca las solicitÃ³. El tono de la conversaciÃ³n es: "AquÃ tiene una solicitud que nunca enviÃ³ y la respuesta llegarÃ¡ pronto..."

+ +

Pero hay restricciones: el cliente puede deshabilitar esta caracterÃstica y el servidor entonces solo podrÃ¡ hacer PUSH en una solicitud que hizo previamente del cliente.

+ +

La intenciÃ³n es permitir al servidor enviar recursos que el cliente seguramente vaya a necesitar, p. ej. un recurso css o javascript que pertenece a una pÃ¡gina html que el cliente solicitÃ³, un grupo de imÃ¡genes a las que se hace referencia en un css, etc.

+ +

La ventaja para el cliente es que ahorra tiempo para solicitudes que pueden tardar desde unos pocos milisegundos a medio segundo, dependiendo de la distancia entre el cliente y el servidor. La desventaja es que el cliente puede recibir cosas que ya tiene en su cache. Por supuesto que HTTP/2 soporta cancelaciÃ³n previa de tales solicitudes, pero aun asÃ se malgastan recursos.

+ +

Resumiendo: no hay una estrategia mejor sobre cÃ³mo usar esta caracterÃstica de HTTP/2 y todo el mundo estÃ¡ experimentando con ella. AsÃ que, Â¿cÃ³mo experimenta usted con ella en Apache httpd?

+ +

mod_http2 busca e inspecciona las cabeceras de respuesta + Link con cierto formato:

+ + +Link </xxx.css>;rel=preload, </xxx.js>; rel=preload + + +

Si la conexiÃ³n soporta PUSH, estos dos recursos se enviarÃ¡n al cliente. Como desarrollador web, puede configurar estas cabeceras o bien directamente en la respuesta de su aplicaciÃ³n o configurar su servidor con:

+ + +<Location /xxx.html> + Header add Link "</xxx.css>;rel=preload" + Header add Link "</xxx.js>;rel=preload" +</Location> + + +

Si quiere usar enlaces con preload sin activar un PUSH, puede usar el parÃ¡metro nopush, como en:

+ + +Link </xxx.css>;rel=preload;nopush + + +

o puede desactivar PUSH para su servidor por completo con la directiva

+ + +H2Push Off + + +

Y hay mÃ¡s:

+ +

El mÃ³dulo mantiene un registro de lo que se ha enviado con PUSH para cada conexiÃ³n (hashes de URLs, bÃ¡sicamente) y no harÃ¡ PUSH del mismo recurso dos veces. Cuando la conexiÃ³n se cierra, la informaciÃ³n es descartada.

+ +

Hay gente pensando cÃ³mo un cliente puede decirle al servidor lo que ya tiene, para evitar los PUSH de esos elementos, pero eso algo muy experimental ahora mismo.

+ +

Otro borrador experimental que ha sido implementado en + mod_http2 es el Campo de Cabecera + Accept-Push-Policy en la que un cliente puede, para cada solicitud, definir quÃ© tipo de PUSH acepta.

+ + diff --git a/docs/manual/howto/http2.xml.meta b/docs/manual/howto/http2.xml.meta index 04a0158938..368861be37 100644 --- a/docs/manual/howto/http2.xml.meta +++ b/docs/manual/howto/http2.xml.meta @@ -8,6 +8,7 @@ en + es fr diff --git a/docs/manual/howto/index.html b/docs/manual/howto/index.html index 7c5b454a3e..4b14fb4150 100644 --- a/docs/manual/howto/index.html +++ b/docs/manual/howto/index.html @@ -4,6 +4,10 @@ URI: index.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: index.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + URI: index.html.fr Content-Language: fr Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/howto/index.xml.es b/docs/manual/howto/index.xml.es new file mode 100644 index 0000000000..55ef7b3219 --- /dev/null +++ b/docs/manual/howto/index.xml.es @@ -0,0 +1,145 @@ + + + + + + + + + + + + How-To / Tutoriales + +

+ + How-To / Tutoriales + +

AutenticaciÃ³n y AutorizaciÃ³n

AutenticaciÃ³n es un proceso en el cual se verifica + que alguien es quien afirma ser. AutorizaciÃ³n es cualquier + proceso en el que se permite a alguien acceder donde quiere ir, + o a obtener la informaciÃ³n que desea tener.

+ +

Ver: AutenticaciÃ³n, AutorizaciÃ³n

+ +

Control de Acceso

Control de acceso hace referencia al proceso de restringir, o + garantizar el acceso a un recurso en base a un criterio arbitrario. + Esto se puede conseguir de distintas formas.

+ +

Ver: Control de Acceso

+ +

Contenido DinÃ¡mico con CGI

El CGI (Common Gateway Interface) es un mÃ©todo por el cual + un servidor web puede interactuar con programas externos de + generaciÃ³n de contenido, a ellos nos referimos comÃºnmente como + programas CGI o scripts CGI. Es un mÃ©todo sencillo para mostrar + contenido dinÃ¡mico en tu sitio web. Este documento es una + introducciÃ³n para configurar CGI en tu servidor web Apache, y de + inicio para escribir programas CGI.

+ +

Ver: CGI: Contenido DinÃ¡mico

+ +

Ficheros .htaccess

Los ficheros .htaccess facilitan una forma de + hacer configuraciones por-directorio. Un archivo, que + contiene una o mÃ¡s directivas de configuraciÃ³n, se coloca en un + directorio especÃfico y las directivas especificadas solo aplican + sobre ese directorio y los subdirectorios del mismo.

+ +

Ver: .htaccess files

+ +

HTTP/2 con httpd

HTTP/2 es la evoluciÃ³n del protocolo de capa de aplicaciÃ³n mÃ¡s conocido, HTTP. + Se centra en hacer un uso mÃ¡s eficiente de los recursos de red sin cambiar la + semÃ¡ntica de HTTP. Esta guÃa explica como se implementa HTTP/2 en httpd, + mostrando buenas prÃ¡cticas y consejos de configuraciÃ³n bÃ¡sica. +

+ +

Ver: GuÃa HTTP/2

+ + +

IntroducciÃ³n a los SSI

Los SSI (Server Side Includes) son directivas que se colocan + en las pÃ¡ginas HTML, y son evaluadas por el servidor mientras + Ã©ste las sirve. Le permiten aÃ±adir contenido generado + dinÃ¡micamente a una pÃ¡gina HTML existente, sin tener que servir + la pÃ¡gina entera a travÃ©s de un programa CGI u otro mÃ©todo + dinÃ¡mico.

+ +

Ver: Server Side Includes (SSI)

+ +

Directorios web Por-usuario

En sistemas con mÃºltiples usuarios, cada usuario puede tener + su directorio "home" compartido usando la directiva + UserDir. Aquellos + que visiten la URL http://example.com/~username/ + obtendrÃ¡n contenido del directorio del usuario "username" + que se encuentra en el directorio "home" del sistema.

+ +

Ver: + Directorios Web de Usuario (public_html)

+ +

GuÃa de Proxy Inverso

Apache httpd ofrece muchas posibilidades como proxy inverso. Usando la + directiva ProxyPass asÃ como + BalancerMember puede crear + sofisticadas configuraciones de proxy inverso que proveen de alta + disponibilidad, balanceo de carga, clustering basado en la nube y + reconfiguraciÃ³n dinÃ¡mica en caliente.

+ +

Ver: GuÃa de Proxy Inverso

+ +

+ + + + diff --git a/docs/manual/howto/index.xml.meta b/docs/manual/howto/index.xml.meta index 75fbfff410..295c1e7609 100644 --- a/docs/manual/howto/index.xml.meta +++ b/docs/manual/howto/index.xml.meta @@ -8,6 +8,7 @@ en + es fr ja ko diff --git a/docs/manual/howto/public_html.html b/docs/manual/howto/public_html.html index 7a9715bd53..4eb8cbede2 100644 --- a/docs/manual/howto/public_html.html +++ b/docs/manual/howto/public_html.html @@ -4,6 +4,10 @@ URI: public_html.html.en Content-Language: en Content-type: text/html; charset=ISO-8859-1 +URI: public_html.html.es +Content-Language: es +Content-type: text/html; charset=ISO-8859-1 + URI: public_html.html.fr Content-Language: fr Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/howto/public_html.xml.es b/docs/manual/howto/public_html.xml.es new file mode 100644 index 0000000000..05e72e8789 --- /dev/null +++ b/docs/manual/howto/public_html.xml.es @@ -0,0 +1,198 @@ + + + + + + + + + + +How-To / Tutorials + + Directorios web por usuario + +

En sistemas con mÃºltiples usuarios, cada usuario puede tener un website + en su directorio home usando la directiva UserDir. Los visitantes de una URL + http://example.com/~username/ recibirÃ¡n el contenido del + directorio home del usuario "username", en el subdirectorio + especificado por la directiva UserDir.

+ +

Tenga en cuenta que, por defecto, el acceso a estos directorios + NO estÃ¡ activado. Puede permitir acceso cuando usa + UserDir quitando el comentario de la lÃnea:

+ + + #Include conf/extra/httpd-userdir.conf + + +

En el fichero por defecto de configuraciÃ³n conf/httpd.conf, + y adaptando el fichero httpd-userdir.conf segÃºn sea necesario, + o incluyendo las directivas apropiadas en un bloque + Directory dentro del fichero + principal de configuraciÃ³n.

+ +Mapeando URLs al sistema de ficheros + + + +

+ Configurando la ruta del fichero con UserDir + +

La directiva UserDir + especifica un directorio del que cargar contenido por usuario. Esta directiva + puede tener muchas formas distintas.

+ +

Si se especifica una ruta que no empieza con una barra ("/"), se asume que + va a ser una ruta de directorio relativa al directorio home del usuario + especificado. Dada Ã©sta configuraciÃ³n:

+ + +UserDir public_html + + +

La URL http://example.com/~rbowen/file.html se traducirÃ¡ en + la ruta del fichero /home/rbowen/public_html/file.html

+ +

Si la ruta que se especifica comienza con una barra ("/"), la ruta del + directorio se construirÃ¡ usando esa ruta, mÃ¡s el usuario especificado en la + configuraciÃ³n:

+ + +UserDir /var/html + + +

La URL http://example.com/~rbowen/file.html se traducirÃ¡ en + la ruta del fichero /var/html/rbowen/file.html

+ +

Si se especifica una ruta que contiene un asterisco (*), se usarÃ¡ una ruta + en la que el asterisco se reemplaza con el nombre de usuario. Dada Ã©sta configuraciÃ³n:

+ + +UserDir /var/www/*/docs + + +

La URL http://example.com/~rbowen/file.html se traducirÃ¡ en + la ruta del fichero /var/www/rbowen/docs/file.html

+ +

+ + +UserDir public_html /var/html + + +

Para la URL http://example.com/~rbowen/file.html, + Apache buscarÃ¡ ~rbowen. Si no lo encuentra, Apache buscarÃ¡ + rbowen en /var/html. Si lo encuentra, la URL de mÃ¡s + arriba se traducirÃ¡ en la ruta del fichero + /var/html/rbowen/file.html

+ +

+ Redirigiendo a URLs externas +

La directiva UserDir puede + usarse para redirigir solcitudes de directorios de usuario a URLs externas.

+ + +UserDir http://example.org/users/*/ + + +

El ejemplo de aquÃ arriba redirigirÃ¡ una solicitud para + http://example.com/~bob/abc.html hacia + http://example.org/users/bob/abc.html.

+ +

Usando la sintaxis que se muestra en la documentaciÃ³n de UserDir, usted + puede restringir a quÃ© usuarios se les permite usar esta funcionalidad:

+ + +UserDir disabled root jro fish + + +

La configuraciÃ³n de aquÃ arriba permitirÃ¡ a todos los usuarios excepto a + los que se listan con la declaraciÃ³n disabled. Usted puede, + del mismo modo, deshabilitar esta caracterÃstica para todos excepto algunos + usuarios usando una configuraciÃ³n como la siguiente:

+ + +UserDir disabled +UserDir enabled rbowen krietz + + +

Vea la documentaciÃ³n de UserDir para mÃ¡s + ejemplos.

+ +

+ Activando un directorio cgi para cada usuario + +

Para dar a cada usuario su propio directorio cgi-bin, puede usar una directiva + Directory + para activar cgi en un subdirectorio en particular del directorio home del usuario.

+ + +<Directory "/home/*/public_html/cgi-bin/"> + Options ExecCGI + SetHandler cgi-script +</Directory> + + +

Entonces, asumiendo que UserDir estÃ¡ configurado con la + declaraciÃ³n public_html, un programa cgi example.cgi + podrÃa cargarse de ese directorio asÃ:

+ + + http://example.com/~rbowen/cgi-bin/example.cgi + + +

+ +

+ Permitiendo a usuarios cambiar la configuraciÃ³n + +

Si quiere permitir que usuarios modifiquen la configuraciÃ³n del servidor en + su espacio web, necesitarÃ¡n usar ficheros .htaccess para hacer + estos cambios. AsegÃºrese de tener configurado AllowOverride con un valor suficiente que permita a + los usuarios modificar las directivas que quiera permitir. + Vea el tutorial de .htaccess para obtener detalles adicionales sobre cÃ³mo funciona.

+ +

+ + diff --git a/docs/manual/howto/public_html.xml.meta b/docs/manual/howto/public_html.xml.meta index 30c006edff..d942792ef1 100644 --- a/docs/manual/howto/public_html.xml.meta +++ b/docs/manual/howto/public_html.xml.meta @@ -8,6 +8,7 @@ en + es fr ja ko -- 2.50.1

Control de Acceso

Consulte también

Advertencia:

Autenticación y Autorización

Consulte también

Nota:

Nota:

Tutorial de Apache: Contenido Dinámico con CGI

Consulte también

Tutorial del Servidor Apache HTTP: Ficheros .htaccess

Consulte también

Nota:

Ejemplo:

Contenido de fichero .htaccess en + /www/htdocs/example

Sección de su fichero httpd.conf

Guía HTTP/2

Consulte también

Escoger un SSLCipherSuite seguro

Notas sobre Mac OS homebrew

Contenido de fichero .htaccess en + `/www/htdocs/example`

Sección de su fichero `httpd.conf`