ASP to ASP.NET Session Variables

2020-02-05 18:07发布

问题:

We have a website in classic asp that we are slowly migrating to ASP.NET as necessary.

The problem of course is how classic asp and ASP.NET handle Sessions. After spending the last few hours researching the web, I found many articles, but not one that stood out over the others.

Is there a best practice for transferring session variables from and to classic asp and asp.net? Security is a must and any explanation with examples is much appreciated.

回答1:

A simple bridge to pass a single session variable from classic asp to .net serverside (hiding your sessionvalue from the client), would be this:

  • On the ASP end: An asp page to output your session, call it e.g. asp2netbridge.asp

    <%
    'Make sure it can be only called from local server '
    if (request.servervariables("LOCAL_ADDR") = request.servervariables("REMOTE_ADDR")) then
        if (Request.QueryString("sessVar") <> "") then
            response.write Session(Request.QueryString("sessVar"))
        end if
    end if
    %>
    
  • On the .net end, a remote call to that asp page. :

    private static string GetAspSession(string sessionValue)
     {
        HttpWebRequest _myRequest = (HttpWebRequest)WebRequest.Create(new Uri("http://yourdomain.com/asp2netbridge.asp?sessVar=" + sessionValue));
        _myRequest.ContentType = "text/html";
        _myRequest.Credentials = CredentialCache.DefaultCredentials;
        if (_myRequest.CookieContainer == null)
            _myRequest.CookieContainer = new CookieContainer();
        foreach (string cookieKey in HttpContext.Current.Request.Cookies.Keys)
        {
            ' it is absolutely necessary to pass the ASPSESSIONID cookie or you will start a new session ! '
            if (cookieKey.StartsWith("ASPSESSIONID")) {
                HttpCookie cookie = HttpContext.Current.Request.Cookies[cookieKey.ToString()];
                _myRequest.CookieContainer.Add(new Cookie(cookie.Name, cookie.Value, cookie.Path, string.IsNullOrEmpty(cookie.Domain)
                    ? HttpContext.Current.Request.Url.Host
                    : cookie.Domain));
            }
        }
        try
        {
            HttpWebResponse _myWebResponse = (HttpWebResponse)_myRequest.GetResponse();
    
            StreamReader sr = new StreamReader(_myWebResponse.GetResponseStream());
            return sr.ReadToEnd();
        }
        catch (WebException we)
        {
            return we.Message;
        }
    }
    


回答2:

I've used an ajax bridge (for want of a better term), specifically, a classic asp page that reads all session vars into a database with a guid, it then redirects to a .net page passing the guid in the querystring, the asp.net page reads from sql for the given guid and created those vars as sessions.

Eg, in classic asp (pseudocode code - just to give you an idea, use parameterised queries in yours etc):

'#### Create GUID
Dim GUID 'as string
GUID = CreateWindowsGUID() '#### Lots of methods on http://support.microsoft.com/kb/320375

'#### Save session to sql
For Each SessionVar In Session.Contents
   db.execute("INSERT INTO SessionBridge (GUID, Key, Value) VALUES ('" & GUID & "', '" & SessionVar & "', '" & session(SessionVar) & "')")
Next

Then, in a .net page:

'#### Fetch GUID
Dim GUID as string = Request.QueryString("GUID")
session.clear

'#### Fetch from SQL
db.execute(RS, "SELECT * FROM SessionBridge WHERE GUID = '" & GUID & "'")
For Each db_row as datarow in RS.rows
    Session(db_row("Key")) = db_row("Value")
Next

As i say, this is very rough pseudocode, but you can call the asp with a simple background ajax function, then call the .net page for the given GUID.

This has the advantage of not exposing all your vars and values to the client (as post methods do etc).



回答3:

They use different sessions, so you'll need to devise some way of transferring the vars yourself. You could include them in cookies, or send them via HTTP POST (i.e. a form with hidden fields) to the asp.net side.

Alternatively, you could scrap using session storage and stick everything in a database for each user/session, then just pass a session key from classic ASP to ASP.NET via one of the above suggestions. I know this sounds like you're reinventing the wheel, but this might be one of those cases where you just can't get around it.



回答4:

I have a website that does that exact action. The secret is to use an intermediate page with the asp function response.redirect

<%
client_id = session("client_id")
response.redirect "aspx_page.aspx?client_id=" & client_id
%>

This is an example to pull the classic asp session variable client_id and pass it to an aspx page. Your aspx page will need to process it from there.

This needs to be at the top of a classic asp page, with no HTML of any type above. IIS will process this on the server and redirect to the aspx page with the attached query string, without sending the data to the client machine. It's very fast.



回答5:

In case anyone else stumbles here looking for some help, another possible option is to use cookies. The benefit of a cookie is that you can store reasonable amounts of data and then persist that data to your .Net application (or another web application). There are security risks with exposing a cookie since that data can be easily manipulated or faked. I would not send sensitive data in a cookie. Here the cookie is only storing a unique identifier that can be used to retrieve data from a table.

The approach:

  1. Grab the session data you need from your classic asp page. Store this data in a table along with a unique hash and a timestamp.
  2. Store the value of the hash in a short-lived cookie.
  3. Redirect to whatever page you need to go and read the hash in the cookie.
  4. Check that the hash in the cookie hasn't expired in the database. If it is valid, send back the data you need to your page and then expire the hash so it can't be reused.

I used a SHA 256 hash that was a combination of the user's unique identifier, session ID, and current timestamp. The hash is valid for only a few minutes and is expired upon reading. The idea is to limit the window for an attacker who would need to guess a valid hash before it expired.