Compartir cookies de sesión ASP.NET con un applet de Java

Question

Tengo un applet de Java que se ejecuta dentro de una página aspx autenticada por formularios. En la versión .NET 1.1 de mi sitio, el applet tiene acceso a la cookie de sesión y puede recuperar un archivo del servidor, pero en la versión .NET 2.0 no puede autenticarse.

He visto un par de publicaciones en foros en otros lugares que indican que 2.0 configura las cookies en HttpOnly de forma predeterminada, pero las soluciones dadas no me han funcionado hasta ahora. También leí en alguna parte que 2.0 puede discriminar según el agente de usuario.

¿Alguien tiene alguna experiencia o conocimiento sobre esto?

Answer 1

Esta pregunta es antigua, pero pensé que era valioso tener la respuesta correcta aquí.

Filip confunde Java del lado del servidor con Java del lado del cliente. Es correcto que no puede compartir sesiones entre dos plataformas del lado del servidor, como Java (J2EE) y ASP.Net sin utilizar un enfoque personalizado.

Sin embargo, los applets son del lado del cliente y, por lo tanto, deberían poder acceder a la información de la sesión de la página del host. El problema es que ASP.Net 2.0 agregó el indicador HttpOnly en las cookies de sesión. Este indicador evita que los applets de JavaScript y Java accedan a estas cookies.

La solución alternativa es desactivar el indicador HttpOnly en las cookies de sesión. Si bien es posible que pueda hacerlo en la configuración en las versiones más recientes de ASP.Net, en versiones anteriores la solución era agregar el siguiente código a su archivo Global.asax:

protected void Application_EndRequest(object sender, EventArgs e)
{
    /**
    * @note Remove the HttpOnly attribute from session cookies, otherwise the 
    *      Java applet won't have access to the session. This solution taken
    *      from
    *      http://blogs.msdn.com/jorman/archive/2006/03/05/session-loss-after-migrating-to-asp-net-2-0.aspx
    *
    *      For more information on the HttpOnly attribute see:
    *
    *      http://msdn.microsoft.com/netframework/programming/breakingchanges/runtime/aspnet.aspx
    *      http://msdn2.microsoft.com/en-us/library/system.web.httpcookie.httponly.aspx
    */
    if (Response.Cookies.Count > 0)
    {
        foreach (string lName in Response.Cookies.AllKeys)
        {
            if (lName == FormsAuthentication.FormsCookieName || 
                lName.ToLower() == "asp.net_sessionid")
            {
                Response.Cookies[lName].HttpOnly = false;
            }
        }
    }
}

Tenga en cuenta que, incluso con esta solución, no todas las combinaciones de navegador / SO / Java pueden acceder a las cookies. Actualmente estoy investigando un problema con las cookies de sesión que no son accesibles en Firefox 4.0.1 con Java 1.6.0_13 en Windows XP.

La solución consiste en utilizar el enfoque que sugirió el Dr. Dad, donde el ID de la sesión se pasa al applet como parámetro y luego se incrusta en la URL de solicitud (requiere que las sesiones de URL se activen en el lado del servidor configuración) o enviado como una cookie configurada manualmente.

Answer 2

Filip es correcto e incorrecto, al menos wrt para Java y ASP.NET. Un applet puede obtener acceso a la sesión ASP.NET haciendo trampa. En mi caso, agregamos el id de sesión como un parámetro al applet, que el applet agrega como una cookie en sus solicitudes. Parece funcionar bien. (¡Encriptamos la identificación de la sesión para frustrar a esa gente hacker desagradable!)

Answer 3

La respuesta de Filip no es del todo correcta. Ejecuté un programa para detectar los encabezados HTTP en mi estación de trabajo, y el applet de Java, de hecho, presenta el ticket de autenticación ASP.NET en algunas circunstancias, pero no lo suficientemente confiable para mis necesidades.

Finalmente encontré una solución a esto, pero no resolvió por completo mi problema. Puede agregar una entrada a web.config en .NET 2.0: <httpCookies httpOnlyCookies="false" />; pero esto no funcionó para todos mis usuarios.

La solución a largo plazo resultó ser la modificación del applet de Java para que no sea necesario recuperar nada del servidor web.

Answer 4

Soy consciente de que puede ser una respuesta muy tardía, pero puedo darle una solución más simple: - por lo general, no siempre, los applets hacen un uso intensivo de html y javascript para sus interfaces e interacción. - Javascript se ejecuta en el navegador. - Las llamadas Ajax son realizadas por el navegador. - Las llamadas Ajax son asíncronas y se pueden integrar fácilmente a una lógica de applets.

Se puede encontrar una solución elegante que integra las llamadas de Ajax a la lógica de un applet, delegando al navegador la seguridad.