Sharing ASP.NET session cookies with a Java applet

Question

I have a Java applet that runs inside a forms-authenticated aspx page. In the .NET 1.1 version of my site, the applet has access to the session cookie and is able to retrieve a file from the server, but in the .NET 2.0 version it fails to authenticate.

I have seen a couple of forum posts elsewhere that state that 2.0 sets cookies to HttpOnly by default, but the solutions given haven't worked for me so far. I also read somewhere that 2.0 may be discriminating based on user-agent.

Does anyone have any experience or insight into this?

Answer 1

This question is old, but I figured it was valuable to have the correct answer here.

Filip is confusing server-side Java with client-side Java. He is correct that you cannot share sessions between two server-side platforms, such as Java (J2EE) and ASP.Net without using a custom approach.

However, applets are client-side and therefore should be able to access the session information of the host page. The issue is that ASP.Net 2.0 added the HttpOnly flag on session cookies. This flag prevents JavaScript and Java applets from accessing these cookies.

The workaround is to turn off the HttpOnly flag on session cookies. While you may be able to do it in the configuration in newer versions of ASP.Net, in previous versions the solution was to add the following code to your Global.asax file:

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;
            }
        }
    }
}

Note that even with this fix, not all browser/OS/Java combinations can access cookies. I'm currently researching an issue with session cookies not being accessible on Firefox 4.0.1 with Java 1.6.0_13 on Windows XP.

The workaround is to use the approach Dr. Dad suggested, where the session ID gets passed to the applet as a parameter, and then either gets embedded into the request URL (requires URL sessions to be turned on in the server-side configuration) or sent as a manually-set cookie.

Answer 2

Filip is both correct and incorrect, at least wrt to Java and ASP.NET. An applet can get access to the ASP.NET session by cheating. In my case, we added the session id as a parameter to the applet, which the applet then adds as a cookie in it's requests. Seems to work ok. (We encrypted the session id to foil those nasty hacker folk!)

Answer 3

Filip's answer isn't entirely correct. I ran a program to sniff the HTTP headers on my workstation, and the Java applet does in fact present the ASP.NET authentication ticket in some circumstances - just not reliably enough for my needs.

Eventually I did find a solution to this, but it didn't entirely solve my problem. You can add an entry to the web.config in .NET 2.0: <httpCookies httpOnlyCookies="false" />; but this didn't work for all my users.

The long term solution turned out to be modifying the Java applet so that it doesn't need to retrieve anything from the web server.

Answer 4

I am aware that it may be a very late answer, but I can give you a simpler solution: - usually, not always, applets make heavy use of html and javascript for their interfaces and interaction. - Javascript is run in the browser. - Ajax calls are made by the browser. - Ajax calls are asynchronous and can be integrated easily to an applets logic.

One can find an elegant solution integrating Ajax calls to an applet's logic, delegating to the browser the security.