Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Otros entornos y lenguajes > PHP
Registrarse FAQ Miembros Calendario Guía de estilo Temas de Hoy

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 10-03-2009
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Cómo implementar un límite de "intentos de acceso"

Hola a todos,

Me encontraba yo esta tarde aburrido, de manera que me he puesto a implementar cierta característica en Gesbit que llevaba tiempo queriendo hacer. La idea es limitar a un número máximo los intentos de acceder al sistema por parte de un usuario. Es decir, existe un formulario para autenticarse, y, el objetivo es que si el usuario intenta "logearse" más de cinco veces, por ejemplo, sin tener éxito, impedirle que continúe intentándolo, cuando menos, no mostrarle más el formulario en cuestión, sino un mensaje de error.

Lo primero que se me ha ocurrido ha sido utilizar una variable de sesión. Craso error. En efecto, funcionaría más o menos bien para un usuario "normal", es decir, alguien llega al formulario de acceso, intenta autenticarse, no lo consigue, y, a la quinta vez, el sistema le retorna un mensaje de error, y no le muestra más el formulario de autenticación hasta que no cierre su sesión de usuario (cierre y vuelva a abrir su navegador). O sea, que sí.

Pero, no. Parece que utililizar una variable de sesión no sirve para el caso de que un usuario intente enviar nuestro formulario de autenticación "desde un script", por ejemplo, escrito en PHP, utilizando la clase Snoopy, haciendo de navegador web. ¡Y precisamente este tipo de usuarios son a los que hay que intentar detener! Puesto que pueden, mediente un "script", hacer tantas peticiones de acceso como les de la gana... intentando así un ataque "por fuerza bruta" al sistema.

Ahora bien, como digo, para este tipo de "scripts", no parecen funcionar las variables de sesión, y es que siempre que el "script" se ejecuta se establece una variable de sesión nueva, de modo que nuestro "contador de intentos de acceso" siempre estaría "a cero". Entonces, mi pregunta es, ¿qué se puede usar aparte de una variable de sesión? ¿No queda más remedio que utilizar la base de datos para guardar allí el número de intentos? ¿Pero dónde se guardaría? ¿En una especie de tabla auxiliar? ¿Acaso no sería esto complicarlo demasiado? ¿Tú sabes de alguna otra solución?

Gracias a todos de antemano por vuestras posibles sugerencias.
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #2  
Antiguo 10-03-2009
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Una pregunta ingenua:

Si algo como Snoopy, genera en el servidor una nueva sesión en cada acceso, ¿qué podría hacer el tal snoopy en nuestro sistema dado que su sesión no se preseva? Esto es, nunca pasaría de la página del login ¿no?

// Saludos
Responder Con Cita
  #3  
Antiguo 10-03-2009
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Bueno. En principio sí que pasaría. El servidor, una vez considerado autenticado al usuario, le serviría la página correspondiente al panel de administración. Pero, en realidad no se prevee que desde Snoopy se hiciera algo, sino que, un "script" podría usar Snoopy para averiguar la respuesta del servidor, podría intentar un "ataque por fuerza bruta".

Se trata de conseguir los datos del usuario Román. Cuando el "script" recibiera "algo" que no fuera "Autenticación fallida", este guardaría el nombre de usuario y contraseña utilizados, puesto que habría conseguido autenticarse. Luego, quien programase el "script" ya haría uso por su cuenta de esos datos... no sé si me explico.

El caso es que, echando un vistazo, no encuentro mucha información en Internet, y, los sistemas que veo que implementan algo así, utilizan la base de datos para guardar el número de intentos de autenticación. Ahora bien, la cuestión es si no hay otra solución a esta (puesto que usar sesiones no da resultado) o si acaso existe otra opción...
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #4  
Antiguo 10-03-2009
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Pérmíteme insistir. Ya sé que usas cookies para mantener la autentificación del usuario, pero, al menos en mis caso, que uso sesiones, es imposible que el usuario haga nada en el sistema si no se preserva la sesión, por el simple hecho de que toda página lleva una sentencia así (ejemplo):

Código PHP:
if (!isset($_SESSION['foo']))
{
  die();

¿Podrías combinar sesiones con cookies?

// Saludos
Responder Con Cita
  #5  
Antiguo 10-03-2009
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Creo que llevas parte de razón al menos, Román, pero, recuerda que no estamos tratando de impedir que se haga algo en el sistema, sino que se pueda acceder al mismo, ¡con los datos del usuario! Se trata de robar las contraseñas, los datos de acceso. Como he dicho arriba, el "script" de Snoopy no trataría de hacer sino eso.

El "script" envía el formulario de autenticación, probando con ciertos "login y password". El "script" sabe que, por ejemplo, cuando en la respuesta del servidor se incluya un "Autenticación fallida", no puede dar por buenos el "login y password" conque ha intentado ese acceso. Pero, como puede hacer infinitos más... sigue probando.

Entonces, en el momento en que el "script" consigue una respuesta del servidor que no sea "Autenticación fallida", el "script" sabe que el login y la contraseña que acaba de probar garantizan el acceso al sistema. No al "script", el "script" habría terminado su trabajo. Simplemente guardaría esos datos.

Ahora, quien programase el "script" diría, Vamos a ver qué hemos pescado hoy. Y, en un archivo, por ejemplo, se encontraría con un mensaje del tipo, "He intentado entrar a esta URL, y, he podido hacerlo con estos datos". Ahora el programador se dirige a la URL (ya no con el "script", sino con un navegador) y usa esos datos para entrar al sistema...

Ahora bien. ¿Qué se hace ante esto? Pues, foros como este, utilizan un "contador de intentos de autenticación". Para evitar el "robo de contraseñas" por la "fuerza bruta". Porque el "script", a la que intentara autenticarse un número determinado de veces, se encontraría con un "Alto ahí, amigo, ya no puedes intentarlo más".

Y eso evitaría (en buena medida) que nadie se planteara robar las contraseñas de un sitio, pues ya no podría hacer, qué sé yo, miles de intentos en una hora, sino que podría hacer no más de unos cuantos al cabo del día... y así podría tardar años en conseguir una contraseña y usuario válidos.

Más o menos ese es el asunto Román.

PD. Usando una base de datos... la cosa es bastante sencilla, como se echará de ver. Yo quisiera evitarlo, porque, no existe una tabla apropiada para tal cosa en Gesbit, de modo que, o bien incluyo una, o bien "encajo" este asunto en una tabla existente... podría preparar un plugin para Gesbit, que se encargara de este asunto, creando la tabla por su cuenta. Pero, considero el asunto lo suficientemente importante como para fuera Gesbit mismo quien diese una solución y no que lo hiciera un plugin.
__________________
David Esperalta
www.decsoftutils.com

Última edición por dec fecha: 10-03-2009 a las 21:42:25.
Responder Con Cita
  #6  
Antiguo 10-03-2009
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Ya, ya. Veo que estaba malentendiendo. Es que estaba comentando en cierta bitácora y no estab poniendo cien por ciento de atención

¿Has probado ese Snoopy vs tu cuenta del Club?

Digo, por curiosidad para saber si el vBulletin resiste.

// Saludos
Responder Con Cita
  #7  
Antiguo 10-03-2009
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Ya lo he visto, ya.

No he probado contra vBulletin, pero, estoy seguro de que resiste, porque, a buen seguro usa la base de datos para este asunto. Ya te digo, Román, en realidad es algo bastante sencillo. El escollo está, básicamente, en "persistir" el contador de intentos de autenticación. Como sé que vBulletin usa la base de datos, estoy seguro de que resistirá también a Snoopy, porque Snoopy no tiene nada que hacer ahí, puede cambiar la sesión de PHP, pero, no puede hacer nada en lo que toca a la base de datos. Igual es que no hay otra forma... usar la base de datos. Dita sea...
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #8  
Antiguo 10-03-2009
pcicom pcicom is offline
Miembro
 
Registrado: may 2003
Ubicación: MONTERREY MEXICO
Posts: 253
Poder: 22
pcicom Va por buen camino
Saludos DEC

Yo lo que hago es manejar el numero de intentos con SESSIONES y en caso de sobrepasar los intentos GRABO la IP y tambien el id del USUARIO para darle un lapso de 15,20,30 minutos para su nuevo REINTENTO..

La logica que utilizo es la siguiente.

1)
El Usuario LLENA el formulario de LOGIN PASSWORD
cuando le da SUBMIT se reenvia a un archivo de VERIFICACION
este archivo CHECA si la IP del NAVEGANTE esta en la BASE de BLOQUEOS
Si esta BLOQUEADO
Muestro MENSAJE de REINENTE mas TARDE
Redirecciono a OTRA PAGINA
No
CHECO LOGIN y PASSWORD en MI BASE
Acumula Numero de INTENTOS
Si Numero de INTENTOS es MAYOR al PERMITIDO
Grabo la IP en la TABLA de BLOQUEO
Si FALLA LOGIN o PASSWORD
Va a (1)
No
ACCESA AL SITIO.



SALUDOS..
__________________
Poco ha de saber el que no pregunta.. Yo por eso soy un pregunton
Responder Con Cita
  #9  
Antiguo 10-03-2009
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Gracias por la respuesta pcicom. ¿Tú usas la base de datos, verdad? El asunto estaría en no tener que usarla, pero, me temo que es necesaria. El caso es que no funcionaría usando sólo la variable de sesión. Es menester "persistir" el contador de intentos, y, ahí es donde entra la base de datos.

Se admiten otras ideas.
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #10  
Antiguo 11-03-2009
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

No sé qué tal parecerá, pero, estoy por implementar el asunto utilizando la tabla "options" que existe ya en Gesbit. De este modo, se añadiría una nueva opción (un nuevo registro) llamado "gbaccessretries", por ejemplo. Este registro sería con el que trabajaría la clase "GbUser", desde el formulario de autenticación y desde el de recuperación de los datos (nuevas contraseñas). Creo que, estirando un poco, una opción así puede caber en dicha tabla. ¿Y vosotros cómo lo veis esto?

PD. Sea como sea, el asunto se complica más de lo que en principio me parecía. No hay que guardar sólo el número de intentos, sino también quién (la IP) hace dichos intentos, luego, tampoco bastaría un registro de una tabla... sino una tabla con varios registros, o varios registros, en todo caso... me temo que de momento voy a recomendar usar contraseñas "fuertes" (), para limitar los ataques por fuerza bruta. Esto hay que tomárselo con mucha más calma.
__________________
David Esperalta
www.decsoftutils.com

Última edición por dec fecha: 11-03-2009 a las 01:11:42.
Responder Con Cita
  #11  
Antiguo 11-03-2009
pcicom pcicom is offline
Miembro
 
Registrado: may 2003
Ubicación: MONTERREY MEXICO
Posts: 253
Poder: 22
pcicom Va por buen camino
Cita:
Empezado por dec Ver Mensaje
Hola,

Gracias por la respuesta pcicom. ¿Tú usas la base de datos, verdad? El asunto estaría en no tener que usarla, pero, me temo que es necesaria. El caso es que no funcionaría usando sólo la variable de sesión. Es menester "persistir" el contador de intentos, y, ahí es donde entra la base de datos.

Se admiten otras ideas.

Pues tambien puedes grabar los INTENTOS y las IP en un archivo de TEXTO, ya seria tu decicion solo tendrias que hacer los barridos buscando la IP y la FECHA HORA del ultimo INTENTO..

Al final de cuentas como la tabla de boqueos va a ser muy pequeña, no afecta en el performance de nada al servidor web,, SALVO que te ataquen por todos lados a tu SITIO...
__________________
Poco ha de saber el que no pregunta.. Yo por eso soy un pregunton
Responder Con Cita
  #12  
Antiguo 11-03-2009
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Sí; ya tengo claro que toca usar la base de datos, mejor que un archivo de texto, aunque, en efecto, sería parecido. Pero como la base de datos existe... podría prepararse ahí lo necesario. Ahora es cuestión de ponerme con ello, si es que decido hacerlo. El caso es que este asunto no puede hacerse con sesiones, por lo dicho al principio. Y no es tan sencillo como yo lo había previsto en principio. Pero, sea como sea, dando por supuesto el uso de la base de datos, es cuestión de ponerse a ello. Gracias pcicom por tu interés.
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #13  
Antiguo 11-03-2009
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
A ver, no quiero quitar el dedo del renglón.

El problema para usar sesiones es que herramientas como Snoopy no tienen manera de guardar las cookies que reciben, incluida la PHPSESSID de sesión, y por tanto, en cada petición, el servidor piensa que es la primera y genera una nueva sesión.

Ahora bien, ésta no es la situación de un usuario normal, y si alguien quiere usar Snoopy para algún fin lícito, tendrá que preocuparse por como preservar esa cookie y enviarla al servidor.

Entonces, el problema está con los chicos malos que intentarán confundir al servidor explotando esta particularidad.

Siendo así, ¿por qué no aprovechar esta amnesia de sesión para detectar si alguien no está jugando limpio?

La idea es generar un valor aleatorio o token al momento de presentar el formulario de login. Este valor se guarda en la sesión y se manda junto con el formulario como un campo hidden. El script que recibe los datos del formulario, verifica que exista dicho campo oculto y que su valor coincida con el que tiene guardado en la sesión.

Esto, de entrada, impide usar Snoopy para invocar directamente al script que procesa el formulario -los datos tiene que enviarse forzosamente desde el formulario que presentamos nosotros mismos. Snoopy podría "leer" ese formulario, usar el DOM para leer el campo oculto y enviarlo junto con la petición al script procesador. Esto es lo que haría alguien que quiere utilizar Snoopy u otra herramienta similar con un fin genuino. Pero si no es así, entonces la sesión no se preservará y el script que recibe los datos del formulario no reconocerá el campo escondido pues no lo tendrá guardado en la sesión, y, de esta manera, sabrá que se trata de una petición no válida.

En resumen, que les damos una cucharada de su propia medicina.

¿Cómo ven?

Claro que esto no invalida la opción de usar la base de datos, pero es una alternativa que, de hecho, se usa con frecuencia para dar mayor seguridad a nuestros formularios de login (buscar forms+tokens en google).

// Saludos
Responder Con Cita
  #14  
Antiguo 11-03-2009
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Hola,

Creo que me enredé demasiado con los tokens.

Basta guardar una variable de sesión cualquiera en la página que muestra el formulario y preguntar por ella en el script que procesa el formulario.

Si no existe la variable, consideramos inválida la petición y abortamos. El atacante podrá hacerlo cuantas veces quiera que siempre obtendrá la misma respuesta: "petición no válida".

La única forma que tiene para no obtener dicha respuesta es preservando la sesión, y una vez hecho esto ya lo tenemos amarrado y podemos contar los intentos con una variable de sesión, que, de hecho, puede ser la misma que la otra:

login-form.php
Código PHP:
<?php
session_start
();
$_SESSION['intentos'] = 0;
?>
<form method='post' action='login.php'>
    <div>
        <label for='user'>User</label>
        <input type='text' name='user' id='user'>
    </div>

    <div>
        <label for='password'>Pwd</label>
        <input type='text' name='password' id='password'>
    </div>

    <div>
        <input type='submit'>
    </div>
</form>

login.php
Código PHP:
<?php
session_start
();

if (!isset(
$_SESSION['intentos']))
{
  die(
'Petición no válida');
}

/*
  Verificamos los datos de inicio
*/

...

/*
  Si son incorrectos, marcamos un intento más
*/

$_SESSION['intentos']++;

/*
  Y lo mandamos a volar si ya rebasó el máximo permitido
*/
if ($_SESSION['intentos'] > 3)
{
  die(
'Demasiados intentos');
}
?>
// Saludos
Responder Con Cita
  #15  
Antiguo 12-03-2009
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Antes de nada, te agradezco el interés Román, doblemente, por la posible solución. Digo posible, porque, aunque todavía no lo he probado tal como dices, me entran dudas sobre el uso de las sesiones, puesto que es lo que había intentado anteriormente. ¿No se supone que las variables de sesión son únicas para cada sesión? Pero, si el "script" cambia dicha variable de sesión... ¿no estamos como al principio? Pero, igual es que no he leído bien tus mensajes Román.

Echaré un vistazo, haré las pruebas oportunas, y comentaré aquí los resultados. Gracias de nuevo Román.
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #16  
Antiguo 12-03-2009
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Cita:
Empezado por dec Ver Mensaje
Pero, si el "script" cambia dicha variable de sesión... ¿no estamos como al principio?
No podemos evitar que nos cambien la sesión. El punto aquí es que si lo hacen, nosotros lo detectamos y los mandamos a volar. Dicho de otra forma, la única manera de que puedan autenticarse en nuestro sistema es no cambiando la sesión, con lo cual tenemos un ambiente controlado.

Olvídate un poco de los tokens (son útiles pero no se requiere tanto) y fíjate en el ejemplo que puse:

1. Es imposible llamar directamente a login.php pues no habrá ninguna sesión y por tanto ninguna variable $_SESSION['intentos']

2. Esta variable se establece en login-form.php

3. Si en el paso de login-form.php a login.php cambia el ID de sesión, entonces login.php ya no reconocerá la variable intentos.

1 y 3 vienen a ser lo mismo. El caso es que ni siquiera se llega a verificar usuario y contraseña, y por tanto el atacante no tiene forma de decidir si eran datos correctos o no.

// Saludos
Responder Con Cita
  #17  
Antiguo 12-03-2009
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

Bueno. Ahora mismo lo que más me llama la atención, es que, en el caso de Gesbit, existe un "user-login.php", donde se realiza la autenticación. No hay dos "scripts", sino uno solamente. Pero, perdona que insista Román (porque igual lo de los "tokens" resulte más conveniente), precisamente, porque no contamos con una sesión "estable", es que no podemos basarnos en ella para este caso.

1º Establezco la variable de sesión "contador"

2º Reviso si existe la variable contador (para incrementarla, si es preciso) ¡Error!

No existe la variable "contador"... no se ha establecido para la sesión "actual"... porque el "script" (Snoopy) siempre juega con una nueva sesión, la variable "contador" ya no existe..., dicho de otro modo, siempre estaríamos estableciendo una variable "contador", pero, no podríamos incrementar esa misma variable contador: de ahí la necesidad de usar una base de datos... para hacer persistir sí o sí esa información, para desligarla de la sesión de usuario.

¿No?
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #18  
Antiguo 12-03-2009
Avatar de roman
roman roman is offline
Moderador
 
Registrado: may 2003
Ubicación: Ciudad de México
Posts: 20.269
Poder: 10
roman Es un diamante en brutoroman Es un diamante en brutoroman Es un diamante en bruto
Por un sólo script, me imagino que te refieres a que el mismo presenta el formulario y el mismo procesa los datos. Pero aún así son dos scripts distintos: el mismo a dos tiempos.

Sería algo así:

user-login.php
Código PHP:
<?php
session_start
();

if (
$_SERVER['REQUEST_METHOD'] == 'POST')
{
    
// Aquí el "segundo" script

    
if (!isset($_SESSION['intentos']))
    {
      die(
'Petición no válida');
    }

    
/*
      Verificamos los datos de inicio
    */

    
...

    
/*
      Si son incorrectos, marcamos un intento más
    */

    
$_SESSION['intentos']++;

    
/*
      Y lo mandamos a volar si ya rebasó el máximo permitido
    */
    
if ($_SESSION['intentos'] > 3)
    {
      die(
'Demasiados intentos');
    }

    exit;
}

$_SESSION['intentos'] = 0;
?>
<form method='post' action='login.php'>
    <div>
        <label for='user'>User</label>
        <input type='text' name='user' id='user'>
    </div>

    <div>
        <label for='password'>Pwd</label>
        <input type='text' name='password' id='password'>
    </div>

    <div>
        <input type='submit'>
    </div>
</form>
Cita:
Empezado por dec
2º Reviso si existe la variable contador (para incrementarla, si es preciso) ¡Error!
¡Exacto! Ése es el punto. Si no existe la variable contador, es un error. No es que haya que volverla a inicializar, es un error y le mandamos el

Código PHP:
die('Petición no válida'); 
La única forma en que no se dé ese error es teniendo definida esa variable de sesión y eso lo hacemos al presentar el formulario. Si el listillo nos cambia la sesión pues el afectado es él porqué recibira el error.

// Saludos
Responder Con Cita
  #19  
Antiguo 12-03-2009
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
Hola,

A ver, que, quiero cogerle el punto (atentos argentinos queridos, cogerle el punto aquí significa lo que significa, ¡y nada más!).

Cita:
Empezado por Román
La única forma en que no se dé ese error es teniendo definida esa variable de sesión y eso lo hacemos al presentar el formulario. Si el listillo nos cambia la sesión pues el afectado es él porqué recibira el error.
Hum... o sea, tratar de aprovechar, precisamente, que no se puede mantener la sesión en condiciones. Pero, ¿esto cómo lo hacemos? Pongámonos en el caso.

El "script" (Snoopy) enviará, directamente, el formulario. Luego siempre estaremos "como en un principio". Siempre será "la primera vez" que se trata de envíar nuestro formulario. Si establecemos una variable de sesión ahí, de nada nos serviría, porque, no la tendríamos a nuestra disposición la siguiente vez. Pero, no sabríamos si es que es la siguiente vez (después de haberla establecido) o no, porque, como el "script" inicia una sesión nueva cada vez... siempre será como la primera vez (argentinos, que os veo con el cachondeíto).

No termino de verlo claro Román. El "script" (Snoopy) no quiere entrar en nuestro sistema, sólo quiere saber si el formulario se procesa bien o mal, si consigue autenticarse con unos datos de usuario, o no lo consigue. No es posible que mantenga (de hecho, ni querrá hacerlo) una sesión de usuario, luego nosotros no podemos basarnos en sesiones de usuario... simplemente es que no podemos... yo lo ví tan claro (que podía hacerse) que hasta me precipité en implementarlo, pero, en cuanto probé con Snoopy... caí en la cuenta de que no podía basarse algo así en variables de sesión: porque no podemos contar con una sesión de usuario.
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
  #20  
Antiguo 12-03-2009
Avatar de dec
dec dec is offline
Moderador
 
Registrado: dic 2004
Ubicación: Alcobendas, Madrid, España
Posts: 13.119
Poder: 34
dec Tiene un aura espectaculardec Tiene un aura espectacular
¿Te convenciste?
__________________
David Esperalta
www.decsoftutils.com
Responder Con Cita
Respuesta



Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro

Temas Similares
Tema Autor Foro Respuestas Último mensaje
Como hacer que se vea "Si" en vez de "TRUE" en un DBGrid lu9eui C++ Builder 2 07-08-2007 05:03:13
Acceso a Outlook 2003 Reminders y error "Invalid Variant Operation" saldanaluis Providers 2 24-05-2007 22:17:58
Implementar una nueva opción para la propiedad "FormStyle" JM75 OOP 3 15-02-2007 16:53:44
Implementar "FloodFill" en CLX salvica Gráficos 1 07-09-2004 20:52:45


La franja horaria es GMT +2. Ahora son las 01:32:05.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi