[Perl] Pregunta #3

[Alejandro G. Bedoya]

> Lo que quiero hacer es algo parecido a lo tuyo, pero no es exacto. =
Yo
tengo
> 2 ficheros planos, FICHERO1 y FICHERO2, con datos distintos, pero q=
ue
tienen
> en com=FAn un campo. Entonces yo quiero comparar este campo com=
=FAn en los dos
> ficheros, y los que sean iguales sacarlos.
>
> Es decir, por cada campo del FICHERO1, mirar en todo el FICHERO2, y=
 la
l=EDnea
> que coincida sacar unos datos.
> Esto me implica que por cada entrada del FICHERO1, tengo que recorr=
er todo
> el FICHERO2. Y no son peque=F1os los ficheros. De ah=ED el alto cos=
te
temporal.
>
> No me sirve la forma esta de unirlos. Por eso solo se me ha ocurrid=
o lo de
> JavaScript. =BFSe os ocurre algo mejor?

    Es lo mesmo... El ejemplo del problema es solo una simplificaci=
=F3n para
sacar la idea general y luego aplicarlo a cada caso particular... Y
descubrimos que hay tres formas de hacerlo, la mala, la buena y la PE=
RL. La
tercera forma ya se expuso con el c=F3digo entendible, que en tu caso=
 seria
muy similar...

my %Temporal
foreach my $Fic1 (@IndiceFichero1) {
    $Temporal{$Fic}=3D1;
    }

foreach my $Fic2 (@IndiceFichero2) {
    $Temporal{$Fi2}++;
    }

#Si quieres saber ("sacar") cuales son iguales, solo revisa que el va=
lor sea
igual a 2.

foreach my $Tem (keys %Temporal) {
    if ($Temporal=3D=3D2) { print "Indice $Tem esta duplicado.\n"; }
    }

    Como ya tienes los indices de los duplicados ya puedes hacer con =
ellos
lo que quieras. Obviamente si lo haces directamente sobre el disco ri=
gido,
tal como recomienda Salvador, ser=E1 mucho m=E1s r=E1pido y eficiente=
.
Adicionalmente interesante con esta opci=F3n es que puedes comparar m=
ultiples
archivos, y con hashes de hashes ir marcando donde estan ubicados los
duplicados o triplicados, etc.

    Aqui si se aplica la excelente observaci=F3n de Gunnar porque exa=
ctamente
como son un monton de "warnings" te ahorras tiempo si asignas sobre t=
odo
cuando son archivos inmensamente grandes. Pero ahorita viendo el c=
=F3digo
solamente funciona para el primer foreach, no para el segundo, ya que=
 podr=EDa
haber "warnings" debido a que el indice no es necesariamente asignand=
o en el
primero. Grave problema si el Fichero2 es mucho mas grande que el Fic=
hero1.
(alguna soluci=F3n Gunnar, o no queda de otra).



> S=ED si el expires lo pongo a 0. Al cerrar el navegador se cierra l=
a
conexi=F3n.
> Pero los 15 minutos es por seguridad. Si en 15 minutos el usuario n=
o ha
> realizado ninguna acci=F3n se cierra la conexi=F3n autom=E1ticament=
e, y esto no
lo
> quiero quitar.
> Mi problema es c=F3mo desconectarlos autom=E1ticamente sin cambiar =
esto,
cuando
> cambien de p=E1gina o cierren el navegador.

    Nuevamente te recomiendo que cada vez que usen el programa se
reactualice la cookie para expirar en 15 minutos. Si tu script tiene =
varios
procedimientos (botoncitos que el usuario puede pinchar) haz que el s=
cript
reactualice la cookie expirando en 15 minutos mas, es decir, reescrib=
ela.
As=ED, si el usuario se tarda m=E1s de 15 minutos en darle un pinchaz=
o de un
boton a otro, pues tendr=E1 que logearse de nuevo. Pero si se tarda m=
enos de
15 minutos de darle pinchazo a un boton a otro, su "sessi=F3n" quedar=
=E1
disponible 15 minutos m=E1s.


> =BFA qu=E9 te refieres con lo de POST?=BFNo usas cookies y lo manda=
s todo con
> POST?=BFC=F3mo?

    El problema de usar GET, sobre todo para passwords, es que queda =
todo en
el historial del navegador, es decir, alguien con tres neuronas en el
cerebro puede ver el url:

<FORM ACTION=3D"sistema.pl" METHOD=3D"GET">
<INPUT TYPE=3D"Text" NAME=3D"login">
<INPUT TYPE=3D"Password" NAME=3D"password">
<INPUT TYPE=3D"Submit" NAME=3D"VPverificar" Value=3DAceptar>
</FORM>


        sistema.pl?login=3Djuan&password=3Dsesamo&VPverificar=3Dacept=
ar


    Al usar post los nombres y valores se mandan "ocultos" para el oj=
o
inexperto, por lo que no queda en ningun historial y ya se necesitar=
=E1n
cuatro neuronas para "verlo". Adem=E1s si usas GET para llamar tus "r=
utinas",
por ejemplo:

    sistema.pl?verinforme

    Tambien se quedara en el historial... y cualquier usuario puede
nuevamente ver el historia y seleccionar este URL y ver el informe ul=
tra
secreto. Y aunque para ver el informe verifiques la cookie para saber=
 si se
logeo y puso el password, este tambien qued=F3 en el historial si es =
que lo
mandaste por GET, lo cual ser=EDa un grave error.

    Yo lo que hago es hacer todo un sistema con un solo script de PER=
L,
cuando el usuario entra por primera vez al script por medio del
"sistema.pl", ver=E1 una pantalla de login y password con el respecti=
vo bot=F3n
de aceptar, pero en modo POST. cuando el usuario pone los datos y le =
da
pinchar al boton de aceptar, se manda la misma cadena que hay despues=
 del
"?" en el URL pero de modo oculto. El Action es siempre el mismo
"sistema.pl", por lo que el sistema se esta llamando as=ED mismo
continuamente, pero seg=FAn el bot=F3n submit que pinche el usuario e=
jecutara
diferente rutina porque cada uno deber=E1 de tener un nombre =FAnico =
para
indentificarlo.

    As=ED el sistema detecta que hay una variable nombrada
VPverificar(independientemente de su valor) y entonces se va a la rut=
ina de
verificar el login y password, si no es el correspondiente muestra un=
a
pantalla de error. Si es el correspondiente muestra la pantalla inici=
al del
sistema, con posiblemente tres botones(submits) para ver
"Catalogos"(name=3DVPcatalogos), "Reportes"(name=3DVPreportes),
"Procesos"(name=3DVPprocesos).

    Como dentro de un FORM puedes meter cientos de submits, y solamen=
te al
que le piques se enviara con todos los demas campos, el sistema detec=
ta a
cual le picaste y se va a cualquiera de las tres rutinas y muestra su
pantalla correspondiente con nuevos submits con diferentes nombres. S=
iempre
llamando al mismo "sistema.pl" y siempre usando diferentes nombres =
=FAnicos de
submits para detectar que rutina hay que ejecutar. A trav=E9s de todo=
 el
sistema el usuario siempre vera como URL "sistema.pl" nada m=E1s.

    Como todo fue dentro de POSTs, el usuario solamente podr=E1 entra=
r a
trav=E9s de un solo URL, y este sigue las pantallas y procedimientos =
que hayas
programado. Por lo que no es necesario usar cookies para mantener la
"session". Se p=F3dr=EDa decir que es una "sessi=F3n de procedimiento=
s".

    Esto es relativamente seguro(un pleonasmo, porque la seguridad si=
empre
es relativa) ya que alguien con seis neuronas pensantes puede poner
"sistema.pl?VPreportes=3D1" y accesar a tu pantalla de reportes sin h=
aber
pasado por el login(claro que podr=EDas haber generado una cookie al =
inicio
para verificar la sesion, pero tendrias que estar la verificando a ca=
da
ratito y refrescarla, y finalmente como veremos esto es innecesario e=
xcepto
que le quieras poner doble "seguridad"). OBVIAMENTE para saber que ha=
y este
boton-submit, es porque el usuario vio el c=F3digo HTML de alguna de =
tus
pantallas, o es un programa distribuible, o porque es el programador
despedido y quiere hacerle una maldad a la gente. La forma de evitar =
esto es
muy sencillo, al inicio del sistema ponle:

    if ($ENV{'QUERY_STRING'} =3D~ /VP/) { exit;}

    Si fuiste previsor y le pusiste a todos tus botones-submits el pr=
efijo
VP, no podr=E1n accesar a ninguno de ellos por medio de un url...

    Ahora que si el abusadillo tiene siete neuronas pensantes, puede =
simular
el submit por POST en su maquina poniendo como Action el URL
correspondientede tu sistema. Para evitar esto solamente tienes que
verificar que el "referrer" sea igual al "host"... =3D)

    Hasta donde le he pensado estas son las unicas dos formas de entr=
ar
ilegalmente y excepto que andes snifeando paquetes, al parecer no hay=
 otra
forma de hackearlo. Excepto lo que diga Gunnar si es que aguanto todo=
 este
rollo.

    As=ED, con POSTs y botones-submits-procedimientos resguardados de=
 las dos
formas explicadas puedes hacer un sistema "seguro" sin necesidad de c=
ookies
ni otras formas de mantener sessiones. La sesion termina cuando el us=
uario
se va a otra p=E1gina o cierra el navegador.

    Me fui largo en esta explicaci=F3n, pero considero que es una for=
ma muy
eficiente para hacer sistemas en PERL, adem=E1s espero que sea =FAtil=
 de alguna
manera para aquellos que esta iniciando en esto.


---
Sinceramente...
Alejandro G. Bedoya
InterAccion.COM          Ponemos su Internet en Acci=F3n