2012-06-28 20 views
9

Tenemos un sitio web en ASP clásico que estamos migrando lentamente a ASP.NET según sea necesario.Variables de sesión de ASP a ASP.NET

El problema, por supuesto, es cómo ASP clásico y ASP.NET manejan Sesiones. Después de pasar las últimas horas investigando en la web, encontré muchos artículos, pero ninguno sobresalió sobre los demás.

¿Existe una mejor práctica para transferir variables de sesión desde y hacia asp y asp.net clásicos? La seguridad es una necesidad y cualquier explicación con ejemplos es muy apreciada.

+0

Debería haber terminado para el final de esta semana con la solución que mejor se adapta a nuestras necesidades. También mencionaré algunos otros métodos. Manténgase informado – PsychoDUCK

Respuesta

5

un simple puente para pasar una sola variable de sesión de ASP clásico a serverside .net (ocultar su sessionvalue desde el cliente), sería la siguiente:

  • En el extremo ASP: una página ASP para la producción su sesión, llámelo, por ejemplo 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 
    %> 
    
  • En el extremo .net, una llamada remota a esa página ASP.:

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

Así fue como terminé codificándolo. Olvidé publicar mi respuesta. – PsychoDUCK

+0

¿cuál es el valor de sessionValue aquí? – Sajeetharan

+0

@Sajeetharan No estoy seguro de cuál es su pregunta. La sessionValue es cualquier variable de sesión que desea compartir, por lo que cualquier parámetro de cadena – AardVark71

0

Utilizan sesiones diferentes, por lo que tendrá que idear alguna forma de transferir los vars por su cuenta. Puede incluirlos en las cookies o enviarlos a través de HTTP POST (es decir, un formulario con campos ocultos) al lado de asp.net.

Como alternativa, podría eliminar el uso de almacenamiento de sesión y pegar todo en una base de datos para cada usuario/sesión, luego pasar una clave de sesión de ASP clásico a ASP.NET a través de una de las sugerencias anteriores. Sé que parece que estás reinventando la rueda, pero este podría ser uno de esos casos en los que no puedes evitarlo.

+0

Me gustaría que esta publicación considere todas las soluciones y determine o cree la "mejor" solución, teniendo en cuenta la seguridad. ¿Por qué es uno mejor que el otro? Obviamente, según ciertos escenarios, uno será mejor que el otro, pero no hay una respuesta clara que pueda encontrar en la web. – PsychoDUCK

+0

No hay una respuesta definitiva a esta pregunta, y será imposible etiquetar una respuesta como la "mejor", ya que es un término muy subjetivo. Tendrá que investigar y determinar qué funciona mejor para sus necesidades. Estas son solo algunas ideas, y debe investigarlas en función de sus necesidades. –

+0

Aunque por consideraciones de seguridad, evitaría enviar los vars al cliente (a través de cookies, campos ocultos, etc.). Considere una solución similar a mi segundo párrafo, donde almacena los vars internamente y envía un identificador al cliente. –

3

He usado un puente ajax (a falta de un término mejor), específicamente, una página asp clásica que lee todas las sesiones en una base de datos con un guid, luego redirige a una página .net pasando el guid en la cadena de consulta, la página asp.net lee de sql para el guid dado y creó esos vars como sesiones.

Por ejemplo, en ASP clásico (código de pseudo - sólo para darles una idea, utilizar consultas parametrizadas en el suyo, 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 

Luego, en una página .net:

'#### 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 

Como digo, este es un pseudocódigo muy tosco, pero puede llamar al asp con una simple función de fondo ajax, luego llamar a la página .net para el GUID dado.

Esto tiene la ventaja de no exponer todos sus vars y valores al cliente (como lo hacen los métodos de publicación, etc.).

+0

Esto es muy similar a lo que pensé que era una buena solución. Pero me confundí en base a un artículo de Microsoft que hizo un enfoque similar que requería que se registraran DLL de seguridad, etc. No entiendo por qué fue necesario. Aquí está el enlace http://msdn.microsoft.com/en-us/library/aa479313.aspx. ¿Alguna idea de por qué todo el trabajo adicional mencionado en el artículo de MSDN está allí? Si es necesario en absoluto? – PsychoDUCK

+1

@PsychoDUCK Creo que la versión de Microsoft es más general. Puede almacenar cualquier objeto en una variable de sesión (no solo cadenas), así que supongo que su solución maneja eso. Pero si solo almacena cadenas en variables de sesión, entonces esto funciona bien (solo asegúrese de que los valores de la sesión no tengan comillas o las instrucciones publicadas aquí probablemente se rompan) – Rodolfo

0

Tengo un sitio web que realiza esa acción exacta. El secreto es usar una página intermedia con la función ASP response.redirect

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

Este es un ejemplo clásico de tirar de la sesión de la AEP variables client_id y pasarlo a una página aspx. Su página aspx deberá procesarla desde allí.

Esto debe estar en la parte superior de una página asp clásico, sin HTML de ningún tipo anterior. IIS procesará esto en el servidor y lo redireccionará a la página aspx con la cadena de consulta adjunta, sin enviar los datos a la máquina del cliente. Es muy rápido.

+2

"... sin enviar los datos a la máquina cliente" - Response.Redirect envía la url que contiene el client_id a la máquina del cliente. – Joe

+0

@joe ¿podría 'Server.Transfer' trabajar aquí en su lugar o me falta algo obvio? –

0

En el caso de cualquier otra persona tropieza aquí en busca de un poco de ayuda, otra opción posible es el uso de cookies. El beneficio de una cookie es que puede almacenar cantidades razonables de datos y luego conservar esos datos en su aplicación .Net (u otra aplicación web). Existen riesgos de seguridad al exponer una cookie, ya que los datos pueden manipularse o falsificarse fácilmente. No enviaría datos confidenciales en una cookie. Aquí la cookie solo almacena un identificador único que se puede usar para recuperar datos de una tabla.

El enfoque:

  1. Grab los datos de sesión que necesita de su página ASP clásico. Almacene esta información en una tabla junto con un hash único y una marca de tiempo.
  2. Almacena el valor del hash en una cookie efímera.
  3. Redirige a la página que necesites y lee el hash en la cookie.
  4. Compruebe que el hash en la cookie no haya expirado en la base de datos. Si es válido, envíe de vuelta los datos que necesita a su página y luego expire el hash para que no pueda volver a utilizarse.

Usé un hash SHA 256 que era una combinación del identificador único del usuario, ID de sesión y marca de tiempo actual. El hash es válido por solo unos minutos y expira después de la lectura. La idea es limitar la ventana para un atacante que debería adivinar un hash válido antes de que expire.

Cuestiones relacionadas