Borrar variables de Sesiones

zacktagnan · #1 (**permalink**) 18/01/2006, 06:49

Hola:

Según he leído, para borrar todas las variables de Sesión:

Session.Abandon

Pero tengo, una duda al respecto:

Supongamos un usuario que está accediendo a Internet. tiene dos sitios web abiertos. En cada uno tiene su cuenta de usuario abierta. Cada sitio web emplea la misma forma de guardar los datos de usuarios mientras la cuenta está abierta, es decir, variables de sesión.

Por ejemplo:
El sitio_web_1 tiene unas variables Session("USU_OK_web_1") y Session("PASS_OK_web_1")
El sitio_web_2 tiene unas variables Session("USU_OK_web_2") y Session("PASS_OK_web_2")

La cuestión es:
Si el usuario cerrase una de sus cuentas activas, por ejemplo, la del sitio_web_1, y en este está programado que, al cerrar sesión, se aplica: Session.Abandon

Pregunta:
Se borran las variables de sitio_web_1 pero ¿se borran también las de sitio_web_2 por ser también variables de sesión, y el usuario no podría seguir navegando por la cuenta que sigue abierta en sitio_web_2?

Es decir, con Session.Abandon ?se borran todas las variables que estén habilitadas ó sólo las de la aplicación desde dónde se llama a éste método?

Espero que se me haya entendido.

Saludos,

zacktagnan.
================================================== ===

tammander · #2 (**permalink**) 18/01/2006, 07:03

Veamos si puedo explicartelo lo mejor posible:

- Una session es una cookie que el servidor asigna con un numero entero Long y el nombre del dominio (en el lado del cliente). Si ya de por si es dificil que dos servidores diferentes asignen el mismo numero (Session.sessionID) a un mismo usuario, es precticamente imposible que dos sesiones de diferentes servidores se entremezclen (diferente IP, etc)

- Con session.abandon lo que hace el servidor, a parte de matar el proceso asignado a esa sesion en el servidor es borrar la cookie en el cliente que apunta a ese proceso.

- Te recomiendo que abandones el uso de Session en servidores IIS con ASP ya que muy a menudo se matan esos procesos a los pocos minutos de su falta de uso. No solo no hace caso a session.timeout sino que los propios administradores de los servidores te recomiendan que, o bien uses ASP.Net o PHP si quieres seguir usando correctamente las sessiones o bien abandones el uso de sesiones en ASP por otra técnica debido a la continua limpieza que hace el servidor con las sesiones.

Espero haberte ayudado.

Un saludo

zacktagnan · #3 (**permalink**) 18/01/2006, 07:22

Entonces, aplicando el Session.Abandon se borran las del sitio_web desde se realizó la llamada.

Respecto a lo de las sesiones, si que me he percatado que a veces cuando no has navegado durante un tiempo con la página dónde las tienes abiertas, pues parece que se borran automáticamente, como tu dices.

Pues sí yo últimamente, uso en las páginas que tengo hechas estas variables de Sesión para guardar los datos del usuario.

Tu dices que cambie esto por otra técnica. ¿Qué otra técnica que no sea la de las cookies? Siempre para ASP.

ASP.NET no se nada. Espero aprenderlo el año que viene.

Saludos,

zacktagnan.
================================================== ======

tammander · #4 (**permalink**) 18/01/2006, 11:15

No me refiero a que no uses las cookies, sino a que no uses el objeto Session de forma indiscriminada

Se puede usar (de hecho yo lo uso) para pasar datos entre una página a otra de forma circunstancial (por ejemplo: Session("errores") = "Problemas para conectar con la base de datos" para control de errores o para llevar un array de una pagina a otra) pero no para controlar a un usuario (se puede "perder" su id de sesion). Yo uso cookies pero que no dependen del servidor: Yo les digo cuanto tiempo tienen de vida y cuando eliminarlos.

El problema esta en si el navegador del cliente acepta cookies, pero ese problema tambien lo tienes con las sesiones. La diferencia entre una cookie y una sesion es que la sesion es una "galletita" que identifica a un sitio web y apunta a un proceso en el servidor y una cookie a secas es una "galletita" que solo identifica un sitio web.

No se si he sido suficientemente claro pero te aseguro que me he dado los suficientes batacazos con el objeto session en ASP como para rehuir de ellos. PHP gestiona mil veces mejor sus sesiones y no te digo nada ASP.NET

Un saludo

zacktagnan · #5 (**permalink**) 19/01/2006, 04:56

Yo tampoco quiero cansar a nadie insistiendo.

Cuando preguntaba "¿Qué otra técnica que no sea la de las cookies?", quería decir qué otra técnica alternativa a las sesiones sugieres usar que no sea la de emplear cookies (que no quisiera emplear, porque, como dices, pueden no estar habilitadas en el navegador del cliente)
Por ejemplo, tú dices que usas sesiones para controlar errores, poniendo algo como:
Session("errores") = "Problemas para conectar con la base de datos"

Y que para conservar los datos de usuario no empleas algo como:
Session("USU_Nom") = "Pepito Grillo"

Luego, ¿qué utilizas para guardar estos datos internamente?
Respuesta precisa y detallada, por favor. Y que no sean cookies.

Leí un día algo sobre el objeto Application ¿que podría usarse como el Session para guardar cosas?

Saludos,

zacktagnan.
======================================

tammander · #6 (**permalink**) 19/01/2006, 05:24

Es obvio que si no uso cookies los datos los hago pasar de página a página usando el método GET (QueryString) o POST (Form) cuando se puede. Pero solo cuando no puedo usar cookies.

Lo normal si quieres crearte tu propia gestion de identificacion de usuario es:

Código:

- Comprobar usuario. 
          Si es correcto --> Guardar en DB Hora, Fecha, Id de usuario, Luego identifico esa sesion del usuario con la ID de ese registro y lo hago comparar siempre que sea necesario (con su existencia me vale en la mayoria de los casos)
          Si no es correcto --> Lo comunico, guardo el intento y la IP de donde viene y le dejo entre 3 y 5 veces mas. Si aun asi falla, es IP es baneada a la sexta vez aunque responda correctamente al nombre y contraseña de usuario

Como ves solo necesitas un numero entero largo (tal como hace el objeto Session) que cambia cada vez que el usuario sale y entra como lo cual es imposible que alguien me entre simplemente deshabilitando las cookies y asignando un numero a la cadena de direccion.

El objeto Application es para el servidor y se usa para TODA la aplicacion, tanto para el cliente activo como para el resto. El objeto Session es solo para el cliente. Application lo utilizo por ejemplo para ver que usuarios estan activos en el momento del cierre de aplicacion, entonces veo aquellos usuarios que han cerrado indebidamente su sesion y los borro de la tabla de gestion de accesos.

Espero haber despejado algunas de tus dudas.

Un saludo

zacktagnan · #7 (**permalink**) 23/01/2006, 07:48

Lo siento, pero no llego a entender del todo tu sistema:

"- Comprobar usuario. "

Vale aquí compruebas lo que ha introducido en el formulario con lo que tienes en la tabla Usuarios. Si coincide es que existe el usuario

"Si es correcto --> Guardar en DB Hora, Fecha, Id de usuario, Luego identifico esa sesion del usuario con la ID de ese registro y lo hago comparar siempre que sea necesario (con su existencia me vale en la mayoria de los casos)"

Si existe el usuario, registras la entrada (Hora, Fecha, Id de usuario,...) ¿en otra tabla por ejemplo, Entradas? y ¿te queda con el id de ese nuevo registro que lo metes dentro de una Session("USu_Activo")?

"Si no es correcto --> Lo comunico, guardo el intento y la IP de donde viene y le dejo entre 3 y 5 veces mas. Si aun asi falla, es IP es baneada a la sexta vez aunque responda correctamente al nombre y contraseña de usuario"

¿Como guardas la IP y los intentos?

Luego cuando hablas de cookies, ¿lo haces refiriéndote también a las sesiones (Session("Datos")) ó solo a las cookies propiamente dichas?

Más detalladamente, ¿me puedes decir como es eso de usar el Application y ver los usuarios activos y cerrar las sesiones abiertas?

Saludos,

zacktagnan.
================================================== =====

tammander · #8 (**permalink**) 23/01/2006, 11:42

Supongamos que tienes dos tablas:

Una para usuarios

Código:

CREATE TABLE `usuarios` (                        
            `id` tinyint(10) NOT NULL auto_increment,      
            `nombre` varchar(200) default NULL,            
            `apellidos` varchar(200) default NULL,         
            `direccion` varchar(200) default NULL,         
            `poblacion` varchar(200) NOT NULL default '',  
            `provincia` varchar(200) NOT NULL default '',  
            `pais` varchar(200) NOT NULL default '',       
            `telefono` varchar(10) default NULL,           
            `login` varchar(40) default NULL,              
            `pass` varchar(20) default NULL,               
            `email` varchar(200) default NULL,             
            `ok` varchar(10) NOT NULL default '',          
            `cr` varchar(200) NOT NULL default '',         
            `op` tinyint(10) NOT NULL default '0',         
            UNIQUE KEY `id` (`id`)                         
          ) TYPE=MyISAM

Otra para los accesos de estos

Código:

CREATE TABLE `accesos` (                  
               `id` int(10) NOT NULL auto_increment,       
               `iduser` int(12) NOT NULL default '0',  
               `ip` varchar(25) default '',                
               `fecha` date default NULL,                  
               `hora` time default NULL,                   
               `intentos` int(10) default '0',         
               `idioma` char(2) default '',                
               `referer` varchar(255) default NULL,        
               `navegador` varchar(255) default NULL,
               `ok` tinyint(1) NOT NULL default '0',  
               `blokeo` tinyint(1),    
               `datos` text,                               
               PRIMARY KEY  (`id`),                        
               KEY `ip_fecha` (`ip`,`fecha`)               
             ) TYPE=MyISAM

Bien. La de usuarios se actualiza ya sea por iniciativa del usuario o por el webmaster el cual asigna la contraseña. Vayamos a por la de acceso.

Cuando un usuario accede a tu web, tiene su nombre de usuario y su contraseña. Tambien podemos sacar desde donde viene (IP - variable del servidor: REMOTE_HOST), que tipo de navegador usa (Variable del servidor: HTTP_USER_AGENT, tambien podemos sacar el S.O. que usa con SERVER_SOFTWARE) y cual es su idioma (variable del servidor: HTTP_ACCEPT_LANGUAGE).

Primer paso: Usuario introduce nombe y contraseña, se envia el POST y se compara con la tabla usuarios.

Si existe: Se añade a la tabla accesos el id del usuario, la fecha y la hora y todo lo dicho antes de los server variables y ok=

. Se toma el id de accesos y se pasea por el querystring (cuando digo querystring, digo formularios, cookies y/o sessiones ) comprobandose que es la IP correcta cada página importante.

Si no existe: Se busca en la tabla acceso la IP con la hora y fecha (por ej. SELECT * FROM accesos WHERE IP='xxx.xxx.xxx' AND fecha='Hoy' AND hora > 'ahora-60min' AND hora < 'Ahora')

- Si blokeo = 1 --> Error: Lo siento, pero sistema bloqueado. Ponerse en contacto con admin o esperarse a mañana

- Si intentos > 3 o > 6 --> UPDATE blokeo = 1

- Else --> Se añade IP, fecha, hora y todas las server variables, se añade 1 a los intentos

NOTA: Esto lo he hecho a bote pronto con lo cual no esta comprobado pero la dinámica de trabajo es la correcta.

OTRO TEMA
Usar el global.asa no hace mucha gracia a los admins de sistema pero aqui te dejo un ejemplo base muy clarito del uso de application. Como veras son eventos de control de inicio de la aplicacion y final.

Código:

<script Language="VBScript" RUNAT=Server>
Sub Application_OnEnd()
  Application.Contents.RemoveAll()
End Sub
 
Sub Application_OnStart()
  Application("NumSesion") = 0
  Application("NumVisitas") = 0
End Sub
 
Sub Session_OnEnd()
  Application("NumSesion") = Application("NumSesion") - 1
  Session.Abandon
End Sub
 
Sub Session_OnStart()
  Application("NumSesion") = Application("NumSesion") + 1
  Application("NumVisitas") = Application("NumVisitas") + 1
End Sub 
</script>

Un saludo

zacktagnan · #9 (**permalink**) 24/01/2006, 05:09

Lo siento ser plasta pero,...

Al final, y volviendo a lo que decía al principio de no abusar de usar Sesiones, cuando dices:

"Si existe: Se añade a la tabla accesos el id del usuario, la fecha y la hora y todo lo dicho antes de los server variables y ok= . Se toma el id de accesos y se pasea por el querystring (cuando digo querystring, digo formularios, cookies y/o sessiones ) comprobandose que es la IP correcta cada página importante."

...si que usas SESIONES ó una variable Query, supongo que en un vínculo como siguientePagina.asp?usuNom=<%=variableUsuNom%>

Y la cosa de pasar todo el rato QueryString también es un poco pesado

Saludos,

zacktagnan.
===============================0

JuanRAPerez · #10 (**permalink**) 24/01/2006, 09:43

pesado no es si definis variables sobre todo para los enlaces
por ejemplo

en un include pone solo esto
include_validar.asp

Código PHP:

  <%

dim EnlaceUsuariio

EnlaceUsuario = "session_ID="&session_ID&"&cod_usu="&cod_usu

 y anidando todas las cosas necesarias para saber quien es y si esta logueado

%>

y luego en tus enlaces pones

a_pagina.asp?<%=EnlaceUsuario%>&otraveriable=talco sa

y asi vas ahorrando estar poniendo el sessionID y el codigo del usuario y algun otro requisito para validar

tammander · #11 (**permalink**) 24/01/2006, 10:34

Cita:

Iniciado por zacktagnan

Lo siento ser plasta pero,...

No te preocupes, para eso estamos

Cita:

Iniciado por zacktagnan

Y la cosa de pasar todo el rato QueryString también es un poco pesado

Tan pesado como comprobar la variable de sesion y muuuucho mas seguro ya que eres tu quien define el tiempo de vida de la sesion y no dependes de los procesos en el servidor (siempre ajustados).

Por ej.
Con Sesiones:

if Session("user") <> "" then

Con QueryString

if comprueba(request("UID")) then

en la funcion comprueba haces el código de comprobacion del valor UID. Dicha funcion puede estar en un archivo comun para todas las páginas.

Como te puedes imaginar, es cuestion de gustos aunque tarde o temprano (mas bien temprano) el servidor empezará a recortar el tiempo de vida de las Session dependiendo de los hospedajes que tengan en el equipo (no es lo mismo para un procesador 10 sitios web que 100)

Por otra parte, con el método antes descrito haces uso de la BD pero MySQL, MSSQL, Oracle, etc soportan muchos mas ataques (accesos) que un Windows server 2003

Recuerda que en el momento del diseño y estructuración de un sitio web debes tener en cuenta muchas cosas, entre ellas la cantidad de accesos que se prevee: tendrás que elegir entre dejarselo al sistema (miedo me da) o crear tu propio gestor de sesiones. Tu mismo

Un saludo

zacktagnan · #12 (**permalink**) 26/01/2006, 11:28

Bueno, pues vale.

Te agradezco que hayas respondido cada vez a todas las preguntas realizadas.

Saludos,

zacktagnan.
=====================================

tammander · #13 (**permalink**) 26/01/2006, 12:53

Cita:

Iniciado por zacktagnan

Bueno, pues vale.

Te agradezco que hayas respondido cada vez a todas las preguntas realizadas.

Saludos,

zacktagnan.
=====================================

Nada, nada para eso estamos. Si puedo, te echaré una mano

Un saludo