Variables de sesión de ASP a ASP.NET

session asp-classic

Question

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

El problema, por supuesto, es cómo ASP y ASP.NET clásicos 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.

Answer 1

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

Por ejemplo, en el ASP clásico (código de pseudocódigo, solo para darle una idea, usar consultas parametrizadas en la suya, 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 función de fondo simple ajax, luego llamar a la página .net para el GUID proporcionado.

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

Answer 2

Usan sesiones diferentes, por lo que tendrás que idear alguna forma de transferir los vars por tu 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.

Alternativamente, puede eliminar el uso de almacenamiento de sesión y pegar todo en una base de datos para cada usuario / sesión, y 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.

Answer 3

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 para extraer la variable de sesión asp clásica client_id y pasarla 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ásica, 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.

Answer 4

Un simple puente para pasar una única variable de sesión desde el asp clásico al servidor de .net (ocultando su sessionvalue desde el cliente), sería este:

• En el extremo de la ASP: una página asp para generar su sesión, llámala 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;
  }
  }

Answer 5

En caso de que alguien más tropiece aquí buscando ayuda, otra posible opción es usar 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. Obtenga los datos de la sesión que necesita desde su página asp clásica. Almacene estos datos en una tabla junto con un hash único y una marca de tiempo.
2. Almacene el valor del hash en una cookie efímera.
3. Redirija a la página que necesite para ir y lea el hash en la cookie.
4. Verifique 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.