PAPI Archivos

The PAPI authentication and authorization framework

PAPI@LISTSERV.REDIRIS.ES

Opciones: Vista Clásica

Use Monospaced Font
Por defecto enseñar Text Part
Mostrar todas las cabeceras de correo

Tema: [<< Primero] [< Prev] [Siguiente >] [Último >>]

Print Responder
Antonio José García Lagar <[log in para visualizar]>
Tue, 7 Apr 2009 08:29:09 +0200
text/plain (109 lines)
El Monday 06 April 2009 16:52:58 Diego R. Lopez escribió:
> Hola,
>
> On 6 Apr 2009, at 11:27, Antonio José García Lagar wrote:
> >> Cada atributo que viene en la asercion esta disponible en un array,
> >> que esta
> >> en $poa->{attrList}. El nombre del atributo esta en los elementos
> >> 2i y
> >> el
> >> valor en los 2i+1 (i va de 0 al numero de atributos).
> >> Asi que poniendo en las expresiones $poa->{attrList}[X] deberias
> >> poder
> >> accederlos.
> >
> > Gracias, esto ya había conseguido solucionarlo.
>
> Perfecto!
>
> >> Respecto a esto, he conseguido poner el mod_perl en modo debug
> >> interactivo,
> >> y estoy bastante perdido. En la página como tu dices, hay dos
> >> formularios,
> >> pero de ambos, el Form_Processor solo identifica los campos tipo
> >> hidden:
>
> Yo me imagino que eso se debe a que el parser de HTML que estamos
> usando para
> el procesador de formularios se hace un lio con los divs que esta
> usando la
> pagina para poner el estilo y con el JavaScript que se invoca en el
> onLoad
> al principio del documento...
>
> >> Para solucionar esto he escrito una rutina que lo que hace es que
> >> si no
> >> encuentra un campo en el formulario, que si haya sido definido en la
> >> configuración del PoA, lo crea para que el formulario tenga al
> >> final al
> >> menos todos los campos definidos en el PoA. Eso puede ayudar a
> >> procesar
> >> formularios que se ayuden del javascript para crear nuevos
> >> elementos al
> >> vuelo.
> >>
> >> Insertar en línea 282
> >>       for my $f (keys %{$formProc->{settings}}) {
> >>         my $field = $g->look_down("name",$f);
> >>         if($field == undef) {
> >>           my $h = HTML::Element->new('input', 'name' => $f, 'type' =>
> >> 'hidden' );
> >>           $g->push_content($h);
> >>         }
> >>       }
> >>
> >> Con esto ya consigo enviar a Proquest el formulario con toda la
> >> información
> >> necesaria. Aún así sigo con problemas porque siempre me responde
> >> con un
> >> header 302 que me lleva a un bucle infinito.
> >
> > Ya lo tengo, tenía algún problema con las cookies, pero las he
> > limpiado, he
> > probado de nuevo y ya está. Como he dicho antes, creo que es una
> > buena opción
> > la de añadir al formulario al menos todos los campos que estén
> > definidos en el
> > PoA para evitar algunos problemas cuando la clase
> > HTTP::Request::Form no
> > identifica correctamente los campos del formulario.
>
> Esto suena estupendamente. Gracias, Antonio! Vamos a incorporar esto
> en la gestion
> de forms del proxy.
>
> Es mas, estamos empezando a trabajar en una version completamente
> nueva del proxy,
> con la idea de ser capaces de dar mejores tiempos de respuesta (en
> especial en lo
> relativo a aprovechar cosas como el keep-alive). Me preguntaba si te
> interesaria
> echarnos una mano cuando la cosa este un poco mas madura...

Cuenta con ello (aunque mis conocimientos en perl son limitados)... pero, 
¿esta nueva versión del proxy sería antes o después de liberar la 1.5 de forma 
definitiva?

Creo que en el estado actual de la misma habría que intentar liberarla y 
mantener una rama 1.5.x para correcciones de errores; posponiendo cambios 
grandes para una versión 1.6 puesto que Debian por ejemplo ha dejado de dar 
soporte a apache 1.3 en su versión estable, aunque aún dará para un año en 
oldstable.

Un saludo.
>
> Un saludo,
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
>
> Red.es - RedIRIS
> The Spanish NREN
>
> e-mail: [log in para visualizar]
> jid:        [log in para visualizar]
> Tel:    +34 955 056 621
> Mobile: +34 669 898 094
> -----------------------------------------

ATOM RSS1 RSS2