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
Esconda cabeceras de correo

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

Print Responder
Received: by LISTSERV.REDIRIS.ES (LISTSERV-TCP/IP release 14.5) with spool id 6092065 for [log in para visualizar]; Tue, 7 Apr 2009 08:29:23 +0200 from abel.rediris.es (abel.rediris.es [130.206.24.2]) by listserv.rediris.es (Postfix) with ESMTP id 544565C201 for <[log in para visualizar]>; Tue, 7 Apr 2009 08:29:23 +0200 (CEST) from ovh2.c17.es ([94.23.19.59]) by abel.rediris.es with ESMTP; 07 Apr 2009 08:29:24 +0200 from localhost (localhost.localdomain [127.0.0.1]) by ovh2.c17.es (Postfix) with ESMTP id 6F06F3543B0 for <[log in para visualizar]>; Tue, 7 Apr 2009 08:29:21 +0200 (CEST) from ovh2.c17.es ([127.0.0.1]) by localhost (ns366703.ovh.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj925Pax7PBA for <[log in para visualizar]>; Tue, 7 Apr 2009 08:29:10 +0200 (CEST) from montijo.localnet (4.27.216.87.static.jazztel.es [87.216.27.4]) by ovh2.c17.es (Postfix) with ESMTP id D4D46354234 for <[log in para visualizar]>; Tue, 7 Apr 2009 08:29:10 +0200 (CEST)
Content-Type: text/plain; charset="iso-8859-1"
Date: Tue, 7 Apr 2009 08:29:09 +0200
Reply-To: The PAPI authentication and authorization framework <[log in para visualizar]>
X-Virus-Scanned: Debian amavisd-new at ovh2.c17.es
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-IronPort-Anti-Spam-Filtered: true
Content-Disposition: inline
Sender: The PAPI authentication and authorization framework <[log in para visualizar]>
Received-SPF: None identity=mailfrom; client-ip=94.23.19.59; receiver=lsv.rediris.es; envelope-from="[log in para visualizar]"; x-sender="[log in para visualizar]"; x-conformance=spf_only None identity=helo; client-ip=94.23.19.59; receiver=lsv.rediris.es; envelope-from="[log in para visualizar]"; x-sender="[log in para visualizar]"; x-conformance=spf_only
Emisor: Antonio José García Lagar <[log in para visualizar]>
User-Agent: KMail/1.11.1 (Linux/2.6.27-14-generic; KDE/4.2.1; x86_64; ; )
Organization: Compact Software International SA
X-IronPort-Anti-Spam-Result: AroCAIuP2kleFxM7mWdsb2JhbACBUpRVAQEBAQEICwoHEbR2hA8G
Parts/Attachments: 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