From b55b5a815beff42015702014fb9c1b17b1688bf9 Mon Sep 17 00:00:00 2001 From: Luis Gil Date: Thu, 3 Nov 2016 10:31:16 +0000 Subject: [PATCH] built and translated the english version to spanish. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1767853 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/howto/auth.html.es | 270 ++++++++++++++++++-------------- docs/manual/howto/auth.xml.es | 271 +++++++++++++++++++-------------- 2 files changed, 313 insertions(+), 228 deletions(-) diff --git a/docs/manual/howto/auth.html.es b/docs/manual/howto/auth.html.es index 6125b39456..3b585fd196 100644 --- a/docs/manual/howto/auth.html.es +++ b/docs/manual/howto/auth.html.es @@ -50,8 +50,8 @@ contraseñas
  • Uso de múltiples proveedores
  • Más allá de la Autorización
    • -
  • Authentication Caching
    • -
  • More information
    • +
  • Cache de Autenticación
    • +
  • Más información

    • Consulte también

    top
    @@ -475,81 +475,93 @@ Require group GroupName

    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 proveedior de autenticación - C - - In Apache 2.2 a provider-based - authentication mechanism was introduced to decouple the actual - authentication process from authorization and supporting functionality. - One of the side benefits was that authentication providers could be - configured and called in a specific order which didn't depend on the - load order of the auth module itself. This same provider based mechanism - has been brought forward into authorization as well. What this means is - that the Require directive - not only specifies which authorization methods should be used, it also - specifies the order in which they are called. Multiple authorization - methods are called in the same order in which the - Require directives - appear in the configuration.

    - -

    With the introduction of authorization container directives - such as - <RequireAll> - and - <RequireAny>, - the configuration also has control over when the - authorization methods are called and what criteria determines when - access is granted. See - Authorization Containers - for an example of how they may be used to express complex - authorization logic.

    - -

    By default all - Require - directives are handled as though contained within a - <RequireAny> - container directive. In other words, if - any of the specified authorization methods succeed, then authorization - is granted.

    + 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. +

    -

    Using authorization providers for access control

    -

    Authentication by username and password is only part of the - story. Frequently you want to let people in based on something - other than who they are. Something such as where they are - coming from.

    +

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

    -

    The authorization providers all, - env, host and ip let you - allow or deny access based on other host based criteria such as - host name or ip address of the machine requesting a - document.

    +

    + 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. +

    -

    The usage of these providers is specified through the - Require directive. - This directive registers the authorization providers - that will be called during the authorization stage of the request - processing. For example:

    +

    + 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
    -

    where address is an IP address (or a partial IP - address) or:

    +

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

    Require host domain_name
    -

    where domain_name is a fully qualified domain name - (or a partial domain name); you may provide multiple addresses or - domain names, if desired.

    +

    + 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. +

    -

    For example, if you have someone spamming your message - board, and you want to keep them out, you could do the - following:

    +

    + 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
@@ -557,9 +569,11 @@ Require group GroupName
    </RequireAll> -

    Visitors coming from that address will not be able to see - the content covered by this directive. If, instead, you have a - machine name, rather than an IP address, you can use that.

    +

    + 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
@@ -567,8 +581,11 @@ Require group GroupName
    </RequireAll> -

    And, if you'd like to block access from an entire domain, - you can specify just part of an address or domain name:

    +

    + 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
@@ -578,61 +595,88 @@ Require group GroupName
    </RequireAll> -

    Using <RequireAll> - with multiple <Require> directives, each negated with not, - will only allow access, if all of negated conditions are true. In other words, - access will be blocked, if any of the negated conditions fails.

    +

    + 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. +

    -

    Access Control backwards compatibility

    -

    One of the side effects of adopting a provider based mechanism for - authentication is that the previous access control directives - Order, - Allow, - Deny and - Satisfy are no longer needed. - However to provide backwards compatibility for older configurations, these - directives have been moved to the mod_access_compat module.

    - -

    Note

    -

    The directives provided by mod_access_compat have - been deprecated by mod_authz_host. - Mixing old directives like Order, Allow or Deny with new ones like - Require is technically possible - but discouraged. The mod_access_compat module was created to support - configurations containing only old directives to facilitate the 2.4 upgrade. - Please check the upgrading guide for more - information. +

    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.

    -
    - -
    top
    +

    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. +

    +
    + + +
    top
    -

    Authentication Caching

    -

    There may be times when authentication puts an unacceptable load - on a provider or on your network. This is most likely to affect users - of mod_authn_dbd (or third-party/custom providers). - To deal with this, HTTPD 2.3/2.4 introduces a new caching provider - mod_authn_socache to cache credentials and reduce - the load on the origin provider(s).

    -

    This may offer a substantial performance boost to some users.

    +

    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. +

    top
    -

    More information

    -

    You should also read the documentation for - mod_auth_basic and mod_authz_host - which contain some more information about how this all works. The - directive <AuthnProviderAlias> can also help - in simplifying certain authentication configurations.

    - -

    The various ciphers supported by Apache for authentication data are - explained in Password - Encryptions.

    - -

    And you may want to look at the Access - Control howto, which discusses a number of related topics.

    +

    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.es b/docs/manual/howto/auth.xml.es index e56bdc1418..dc00d9e5d2 100644 --- a/docs/manual/howto/auth.xml.es +++ b/docs/manual/howto/auth.xml.es @@ -1,7 +1,7 @@ - +