views:

100

answers:

1

The company that I work for is making a transition between classic ASP programs and ASP.NET programs for our intranet software. Eventually, everything will be written in ASP.NET, but because of time constraints, there are still a number of programs that use classic ASP.

To compensate we've written features that allow for redirects and autologins between classic ASP programs and ASP.NET programs. I've been starting to see a problem, though, with holding the session state for our ASP.NET software. If a user uses an ASP.NET program, then does work in a classic ASP program, then goes back to that ASP.NET program, often times, the user's authentication for the ASP.NET program is still in place, yet the user's session is lost, resulting in an error whenever a function is performed within the program.

I'm trying to capture the loss of the session state in global.asax's Session_End event, which would redirect the user to the login page, but that hasn't worked. Has anyone else faced a similar issue with users moving back and forth between classic ASP and ASP.NET and losing sessions? Is that even my real issue here? It's the only thing that I can see as being a problem.

EDIT

This is what we do to redirect users to an ASP.NET page from a classic asp page.

We create an MD5 hash based off of the userID and the date and send it to a redirect.aspx page via the query string. From there, the aspx page creates its own MD5 has based off of the userId and the date, both passed via the query string. If the 2 hashes are identical, the user is authenticated, and the program loads. Here is an example:

Classic ASP:

strDate = Year(Now())  & right("0" & Month(Now()), 2) & right("0" & Day(Now()), 2)
key = MD5(SessionUserID & strDate)
Response.Redirect "/redirect.aspx?key="&key&"&lpid="&ProgramID&"&unum="&SessionUserNum&"&uid="&SessionUserID&"&gid="&SessionGroupID

Redirect.aspx:

string key = Request.QueryString["key"];
//SetDesignModeState Variables:
if (getMd5Hash(Request.QueryString["uid"] + DateTime.Today.ToString("yyyyMMdd")) == key)
{
    Session["SessionGroupID"] = Request.QueryString["gid"];
    Session["SessionUserNum"] = Request.QueryString["unum"];
    Session["SessionUserID"] = Request.QueryString["uid"];
    string appID = Request.QueryString["lpid"];
    FormsAuthentication.SetAuthCookie(Request.QueryString["uid"], false);
    //redirect to ASP.NET page...
+3  A: 

Hi Aaron

I've done a similar thing to you: authenticating users from a legacy ASP application to an ASP.NET site. What would help, is if you could provide a little more detail (sample code, perhaps) of the process you've setup to do this with users coming from the legacy app to the ASPX app.

To give you a brief idea, in my implementation I've done the following:

  • Create an .ASPX page
  • The .ASPX page accepts HTTP POST values from a particular legacy ASP app only.
  • When a POST request is received, I extract the username/password values, then proceed to authenticate in the normal way. If the user is successfully authenticated, we issue a FormsAuthentication cookie to the user.

In reality, my implementation is quite a bit more complicated, using the database as a backing store (as both apps share a common data source) and a particular database field to store a random code which is sent from the classic app to the .NET side to further verify that the request received by the .NET app is valid.

EDIT:

Try manually setting your authentication cookie. Delete the line:

FormsAuthentication.SetAuthCookie(Request.QueryString["uid"], false); 

Replace with:

FormsAuthenticationTicket ticket = new FormsAuthenticationTicket(1,
                Request.QueryString["uid"],
                DateTime.Now,
                DateTime.Now.AddHours(24),
                false,
                null)

        string encryptedTicket = FormsAuthentication.Encrypt(ticket);
        HttpCookie cookie = new HttpCookie(FormsAuthentication.FormsCookieName, encryptedTicket);            
        HttpContext.Current.Response.Cookies.Add(cookie);

See how you get on with that?

Richard
I've edited my post for more information.
Aaron
Edited my own post in response...
Richard
Thanks for the suggestion...I'll try it out and let you know how it works.
Aaron
This did help out. Thanks.
Aaron