26 respuestas en este tema

[Caral]

Hola

Mi siguiente duda lógica sería, que pidiese el logín si se abre desde otro punto de la red.????

He aqui que insisto en que la BD tiene que tener el dato de activado.
Si se conecta desde la casa, red o donde sea estará activo.
Creo que es preferible solucionar el problema de caida de sistema por otro lado.
Es que no le hacéis caso al novato 
Saludos

[andres1569]

Hola,

Personalmente no me gusta mucho la idea "SuperGlobal". Si se comparten las propiedades de una clase de forma global ¿donde queda, entonces, la encapsulación? todo el trabajo de la POO lo deshacemos.

Prefiero compartir justo lo necesario y nada mas, así nada se escapará de las manos.     

A mi modo de ver, esta clase TSuperGlobalObject lo que nos da es una forma cómoda y sencilla de compartir ese archivo en memoria, con poco código tenemos tanto los datos que queremos compartir como los métodos para manejarlos, queda claro que esta clase actúa únicamente como contenedor de información, sin más pretensiones. A la clase que derivé le falta implementar, éso sí, algún tratamiento de bloqueo para evitar colisiones.

Mi siguiente duda lógica sería, que pidiese el logín si se abre desde otro punto de la red.????

No sé si te he entendido bien, creo que estos mecanismos para ahorrar "logueos" al usuario sólo deben aplicarse en la misma máquina, si se conecta desde otra máquina pues a loguearse de nuevo, sin duda alguna.

Ahora bien, lo que plantea Wilson es muy cierto, ¿cómo sabes que quien abre una aplicación es Pedro y no Juanito mientras Pedro se iba a tomar un café antes de que saltara el salvapantallas?    Otra cosa es que demos por sentado que cada máquina sólo la maneja un usuario, pero quizás una forma de abordar el asunto sea el que propone Wilson de una aplicación lanzadera de las otras, y ésa es la que controla el login a la BD.

He aqui que insisto en que la BD tiene que tener el dato de activado.
Si se conecta desde la casa, red o donde sea estará activo.
Creo que es preferible solucionar el problema de caida de sistema por otro lado.
Es que no le hacéis caso al novato   
Saludos

¿A cuál de los novatos te refieres?    Porque a medida que le doy vueltas al tema veo que estoy más verde    Lo de almacenar en la base de datos ese valor es un arma de doble filo, como he dicho anteriormente creo que cuando uno se conecta desde una máquina distinta debería autentificarse de nuevo, en realidad todo esto arranca de querer ahorrar trabajo al usuario, pero no hasta tales extremos. Partiendo de la base de que el logueo es un mecanismo de seguridad, el saltárnoslo debería ser sólo cuando tenemos "algunas" garantías (algunas entre comillas), de que quien se conecta es el mismo individuo que lo hizo en la misma máquina un ratito antes, para ahorrarle faena, y aún así entraña algún riesgo (el mismo que si ese individuo se va a mear y alguien que pasaba por allí se sienta a fisgonear el programa frente a su máquina).

Saludos

[hecjona]

Yo lo implemetaria con una DB ->Tablas:usuarios y usuarios_sesiones 
La Usuarios_sesiones tendria los campos
ID  longint *PK
IP  Char(30) /*Listo Para IPV6*/
Inicio timestamp Default : current_timestamp; /*Que funcionaria como Login y LastActivity*/
Finalizo timestamp

delphi

/*Esto va en el fuente del project*/
sIP := ObtieneIP_Local;
IF HaySessionActiva(sIP,Usuario_Actual) then 
  Establece Permisos(Usuario_Actual)
else
   If  PideLogin(sIP,Usuario_Actual) then
        Application.terminate
   else
       Application.run;
function HaySessionActiva(IP:string;var Usuario:Longint):Boolean;
Basicamente busca si hay en usuarios_sesiones hay alguna sesion con la condicion
IP=:IP and ((finalizo is null) and  ( inicio > 'NOW' - (MAX_margen_activo))

En el evento onMouseMove de cada forma llamas al procedure SetSesionActiva que estableceria en la tabla el campo Inicio='Currenttime', de tal forma que si se va la luz o por alguna razon la sesion queda "abierta" tienes un "Max_margen_activo" en minutos para determinar la vida de la sesion.
Algo asi.

[Wilson]

Te adjunto un ejemplo que consta de 3 aplicaciones que apuntan a una DB de access, debes organizar la cadena de conexión según tu caso, la DB tiene una tabla de usuarios y una tabla de aplicaciones con un campo para el nombre de la aplicación y otro para guardar el estado.

La aplicación recepción es la que identifica al usuario y lanza desde allí las otras dos aplicaciones.

Las restantes aplicaciones (A y B) disponen de un form Login que solo se ejecuta cuando estas son llamadas por fuera de la aplicación recepción.  La llamada del Login en las tres aplicaciones se hace desde el código del proyecto mismo.

Espero te sirva de guía.

Saludos

PD: En la llamada  a las aplicaciones desde la recepción debes ajustar la ruta de los ejecutables de A y B.

[Desart]

Creo que he encontrado la respuesta, comentar primero, que si un usuario, se ausenta de su puesto debe ser este quien cierre el usuario, así que a este nivel, no debería haber problemas.


Pensando en como solucionar el tema, pensé lo siguiente, tenemos la aplicación madre que siempre debe usar Login, luego tenemos las auxiliares que lo usarán o no, el tema de las bases de datos no terminaba de convencerme por seguridad, así que resolví por usar llamar a los auxiliares desde el form principal con parámetros, para que me entendáis mejor he creado una demo, con el tema que adjunto a esta respuesta.


Ya mi diréis.


Un Saludo desde Canarias.

Archivos adjuntos

•  2358_9b68ea9e8676d76ee325f761342ebeafbecf8038.zip   844,01KB   8 descargas

[Wilson]

Me alegra que hayas solucionado, definitivamente esa era la idea, loguearse en una sola y desde allí llamar a las otras, y que estas cuando se llamen desde fuera de la aplicación principal pidan login.

Saludos

[Desart]

Pues nada doy el tema por resuelto.