logout - restricted - Cerrar sesión de un usuario al usar la autenticación HTTP básica

set header basic authentication

Question

Quiero que los usuarios puedan iniciar sesión a través de los modos de autenticación HTTP básicos.

El problema es que también quiero que vuelvan a cerrar la sesión; es raro que los navegadores no lo admitan.

Esto se considera un riesgo de piratería social: el usuario deja su máquina desbloqueada y su navegador abierto y alguien más puede visitar el sitio fácilmente como ellos. Tenga en cuenta que simplemente cerrar la pestaña del navegador no es suficiente para restablecer el token, por lo que podría ser una cosa fácil de perder para los usuarios.

Así que he encontrado una solución alternativa, pero es un total cludge:

1) Redirigirlos a una página de cierre de sesión

2) En esa página, active un script para cargar ajax en otra página con credenciales ficticias:

$j.ajax({
    url: ''<%:Url.Action("LogOff401", new { id = random })%>'',
    type: ''POST'',
    username: ''<%:random%>'',
    password: ''<%:random%>'',
    success: function () { alert(''logged off''); }
});

3) Eso siempre debe devolver 401 la primera vez (para forzar que se pasen las nuevas credenciales) y luego solo aceptar las credenciales ficticias:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult LogOff401(string id)
{
    // if we''ve been passed HTTP authorisation
    string httpAuth = this.Request.Headers["Authorization"];
    if (!string.IsNullOrEmpty(httpAuth) &&
        httpAuth.StartsWith("basic", StringComparison.OrdinalIgnoreCase))
    {
        // build the string we expect - don''t allow regular users to pass
        byte[] enc = Encoding.UTF8.GetBytes(id + '':'' + id);
        string expected = "basic " + Convert.ToBase64String(enc);

        if (string.Equals(httpAuth, expected, StringComparison.OrdinalIgnoreCase))
        {
            return Content("You are logged out.");
        }
    }

    // return a request for an HTTP basic auth token, this will cause XmlHttp to pass the new header
    this.Response.StatusCode = 401; 
    this.Response.StatusDescription = "Unauthorized";
    this.Response.AppendHeader("WWW-Authenticate", "basic realm=/"My Realm/""); 

    return Content("Force AJAX component to sent header");
}

4) Ahora el navegador ha aceptado y almacenado en caché las credenciales de cadena aleatoria. Cuando visitan otra página, intentará usarlas, fallará y luego solicitará las correctas.

Tenga en cuenta que mis ejemplos de código utilizan jQuery y ASP.Net MVC, pero lo mismo debería ser posible con cualquier pila de tecnología.

Hay otra forma de hacer esto en IE6 y superior:

document.execCommand("ClearAuthenticationCache");

Sin embargo, eso borra toda la autenticación: se desconectan de mi sitio y también se desconectan de su correo electrónico. Así que eso está fuera.

¿Hay alguna manera mejor de hacer esto?

He visto other questions sobre esto, pero tienen 2 años, ¿hay alguna forma mejor ahora en IE9, FX4, Chrome, etc.?

Si no hay una mejor manera de hacer esto, ¿se puede confiar en este cludge? ¿Hay alguna manera de hacerlo más robusto?

Answer 1

El anser corto es:
No existe un procedimiento confiable para lograr un "cierre de sesión" mediante la autenticación HTTP básica o compendiada dadas las implementaciones actuales de la autenticación básica.

Dicha autenticación funciona haciendo que el cliente agregue un encabezado de autorización a la solicitud.
Si para un determinado recurso el servidor no está satisfecho con las credenciales proporcionadas (por ejemplo, si no hay ninguna), responderá con un código de estado "401 no autorizado" y solicitará la autenticación. Para ese propósito, proporcionará un encabezado WWW-Authenticate con la respuesta.

Un cliente no necesita esperar a que un servidor solicite autenticación. Simplemente puede proporcionar un encabezado de Autorización basado en algunas suposiciones locales (por ejemplo, información en caché del último intento exitoso).

Si bien su enfoque resumido para "eliminar" la información de autenticación tiene una buena posibilidad de trabajar con una amplia gama de clientes (es decir, navegadores generalizados), no hay ninguna garantía de que un cliente diferente sea "más inteligente" y simplemente discrimine los datos de autenticación adecuados para su página de "cierre de sesión" y cualquier otra página del sitio de destino.

Reconocerá un "problema" similar con el uso de la autenticación basada en certificados del lado del cliente. Mientras no haya un apoyo explícito de los clientes, es posible que luchen en el terreno perdido.

Por lo tanto, si el "cierre de sesión" es una preocupación, pase a cualquier autenticación basada en sesión.

Si tiene acceso a la implementación de la autenticación en el lado del servidor, es posible que pueda implementar una funcionalidad que ignorará la información de autenticación presentada con el encabezado de Autorización (si aún es idéntica a la que se presentó durante la "sesión actual") a petición de su código de nivel de aplicación. (o proporcione algún "tiempo de espera" después de lo cual se volverán a solicitar las credenciales), de modo que el cliente le pedirá al usuario que proporcione las credenciales "nuevas" (realizar un nuevo inicio de sesión).