Automatización Web (HTTP sin navegador)

[[seoane]]

Por favor Roman llámame Domingo que hay confianza . Por otro lado, Dec en su truco 346 utiliza un TIdMultiPartFormDataStream, en concreto el método AddFormField para pasar los parámetros, ignoro cual es la mejor forma de hacerlo. A mi también se me hace mas cómodo usar un TStringList, en eso parece que estamos de acuerdo.

Por si tienes curiosidad wininet creo también maneja el código código 302, al menos maneja el 301 . En cuanto a las cookies, ya dije antes que si las maneja, incluso utiliza las cookies guardadas previamente, con el típico "Recordar contraseña" que se encuentra en algunas paginas web.

Pero dejemos este tema a un lado, lo importante es que tanto por un método como por el otro obtenemos un resultado en un Stream. Centremonos entonces en ese punto, yo también estoy esperando haber que solución se puede utilizar para examinar el contenido de la respuesta.

[[Al González]]

¡Hola de nuevo!

Muchas de estas cosas son nuevas para mí. Mi conocimiento actual sobre HTTP se reduce a unas pequeñas prácticas realizadas con PHP en el verano de 2005.

Con un día de retraso en mi agenda, empezaré a probar el componente TIdHttp, muy bien sugerido e ilustrado por David.

Domingo: los enlaces y ejemplos que me indicas me resultaron muy interesantes también. Ya había buscado en los foros, aunque no lo suficiente por lo que veo.

Antonio: habré de molestarte con algunos consejillos cuando me tope con eso de las galletas de sesión (¡mmm, galletas! , de pronto abrírseme el apetito, me acercaré unas con chispas de chocolate que tengo en la cocina...).

Bien, manos a la obra...

Un abrazo HTTP.

Al González.

[[Al González]]

¡Hola a todos!

Ya le eché un vistazo superficial a las propiedades y eventos del componente TIdHTTP. Aquí el curso de mi pensamiento durante dicha labor:

--------------------------------------------------------------------------
Estudio del componente TIdHTTP.
Monólogo de acercamiento inicial.
Por Al González.

¡Vaya! Así que estos son los famosos Indy. Pero qué iconos tan simplones tienen, hasta un gatito aparece ahí...ah no, el diccionario dice que se trata de un «roedor semejante a la ardilla».

Bien, ya agregué un TIdHTTP a mi forma. La primera propiedad que tiene es AllowCookies, y aparece marcada con True negrita, como si su valor predeterminado fuese False. Lo más probable es que no le hayan puesto la cláusula Default a su declaración...Efectivamente, Doychin Bondzhev olvidó hacerlo, o no quiso. Prosigamos...

Curiosa nota en los comentarios de la unidad IdHTTP.pas:

Initially only GET and POST will be supported. As time goes on more will be added…

Sería interesante saber qué otros métodos de envío de datos pueden o podrían implementarse en HTTP.

AuthRetries. Ésta se me hace que la voy a necesitar para el ingreso de usuarios.

CookieManager. Aquí está la propiedad que decía Antonio. Por el momento voy a probar sin control de galletas (porque de hecho ya me las terminé ).

HandleRedirects. Esto me suena a cuando quiero entrar a una página y el navegador me lleva a otra, a veces de forma temporal para decirme que he ganado 50 millones de dólares y churradas similares.

HTTPOptions. Amo las propiedades Options, tienen un no sé qué que siempre te saca de apuros. hoForceEncodeParams está en True, como debe ser; ya había olvidado que en las URLs deben codificarse los caracteres no ingleses para que cualquier servidor Web lo interprete correctamente (ojalá Unicode no pase a la historia como el Esperanto de las comunicaciones, urge su uso difundido).

MaxLineAction, MaxLineLength con valor default de 16384. No dudo que todavía haya programadores que se jactan de su ingenio escribiendo doscientas sentencias en una sola línea.

Port 80. Según he escuchado, el puerto que utilizan los navegadores. Bien.

ProtocolVersion con valor de pv1_1. Ahora que recuerdo, cuando estuve trabajando con un mecanismo de inserción automática de texto HTML en Word, la cabecera del texto llevaba algo de versión al principio. Y si mal no recuerdo, para compatibilidad, la versión usada era la 0.9 (o algo así). Me pregunto si tiene que ver una cosa con la otra y cómo influye esto de la versión en TIdHTTP.

Vaya, la ayuda dice «specifies the HTTP version used for Get, Head, and Post methods for the HTTP client». Entonces sí existen otros métodos (por lo menos uno) además de Get y Post, ¿cómo será eso del método Head?

ProxyParams. ¡Oh-oh! Creo que ha llegado la hora de investigar qué es exactamente un proxy (durante años sólo he tenido la vaga idea de que es una especie de filtro repartidor de Internet, y que por lo regular limita la libertad de los usuarios para no dejarlos trabajar a gusto). A ver Wikipedia, dime quién es el más bonito, digo, dime qué es un proxy. Bien, por lo que veo no estaba tan lejos, es un software (por lo general) que administra, controla y facilita automáticamente los accesos a Internet en una red.

Si el cliente tiene un proxy, supongo tendré que emplear las sub propiedades ProxyUsername y ProxyPassword. Algo a tener en cuenta.

ReadTimeout. Ha de ser el tiempo de espera para recibir una respuesta del servidor Web, aunque la ayuda dice que es «peer connection». Supongo que en este caso el término conexión se refiere a cada orden o submit, enviado al servidor Web, no a la sesión en sí.

Request. «Specifies the header values to send to the HTTP server… Use Response to examine header values received in an HTTP protocol response from the server». Y veo que Response («Specifies the header values received from the HTTP server») es otra propiedad pero no publicada sino pública. Es lógico, puesto que no tendría sentido que apareciese en el inspector de objetos.

Estas dos propiedades me despiertan varias dudas: ¿qué es eso de los valores de cabecera? ¿se referirá a lo del método Head que leí antes? ¿qué utilidad tiene? ¿cómo funciona? Tal vez Dec o Domingo lo sepan, qué chévere es contar con ellos . ¿No tendrán otra cosa que hacer? Siempre están dando respuestas, y bastante buenas, son casi genios.

Tag. Seguro esta propiedad se refiere a las pestañas del navegador Mozilla. ¡Jejeje! es una broma que me hago a mí mismo.

Ahora pasemos al ver los eventos del componente...

Me llaman la atención los cuatro últimos, OnStatus, OnWork (vaya nombre menos descriptivo), OnWorkBegin y OnWorkEnd. Me pregunto qué utilidad tienen. Ah, vaya, el primero como que sirve para saber en qué parte del proceso se encuentra la petición al servidor Web. Los OnWorkXXX no me quedan claros, leeré de nuevo la ayuda; interesante: «OnWork is generally used to control the update of progress indicators or GUI components», dice algo similar para los otros dos.

OK, ya le eché un vistazo general a las propiedades y eventos del componente TIdHTTP. Ahora voy a hacer mi primera prueba (¡qué emoción!). Por lo pronto quisiera empezar con una página distinta a la que requiero acceder con mi aplicación. ¿Qué página estará buena para hacer esta prueba? ¿www.ponchito.com, www.youtube.com?..., ¡ah, ya sé! https://login.yahoo.com/config/mail?.intl=us con una cuenta temporal. Con tu permiso Yahoo...
--------------------------------------------------------------------------

De antemano, gracias por auxiliarme con mis dudas . Seguiremos informando.

Un abrazo índyco.

Al González.

[[seoane]]

Vamos a ver si te puedo explicar algunas cosas, al menos como yo las recuerdo de cuando me ley el protocolo para hacer mi pico servidor . Espero no equivocarme mucho ...

Empezado por Al

Vaya, la ayuda dice «specifies the HTTP version used for Get, Head, and Post methods for the HTTP client». Entonces sí existen otros métodos (por lo menos uno) además de Get y Post, ¿cómo será eso del método Head?

Es verdad, el protocolo http tiene varios comandos los habituales Get y Post, y algunos otros. Ahora mismo solo me acuerdo del Head y el Connect, pero creo que algún otro hay. El Head básicamente es similar al Get solo que el servidor al responder solo devuelve las cabeceras y no el resto de la respuesta, esto puede ser practico, por ejemplo, si queremos obtener información sobre un archivo, como si esta disponible o cuantos bytes ocupa sin tener que descargarlo. El connect se utiliza para establecer túneles a través de los proxys para las conexiones seguras, pero eso ya es otra historia. Hablando de cabeceras ...

Empezado por Al

Estas dos propiedades me despiertan varias dudas: ¿qué es eso de los valores de cabecera? ¿se referirá a lo del método Head que leí antes? ¿qué utilidad tiene? ¿cómo funciona?

En el protocolo http tanto las peticiones (Request) como respuestas (Response) tienen un formato similar. Se dividen en una serie de cabeceras, una linea para cada una y el propio cuerpo del mensaje. Separados por una linea en blanco. Un ejemplo:

Petición de la pagina de google:

GET / HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*
Accept-Language: es
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Host: www.google.es
Proxy-Connection: Keep-Alive

Se puede ver que la primera linea es el comando (Get,Head,Post,etc), las otras cabeceras dan otra información como el Host, el tipo de navegador, etc. Fíjate en la linea en blanco al final, esta indica el final de las cabeceras y el comiendo de los datos, como es un comando get no hay datos, si fuera un comando Post la información se enviaría a continuación de la linea en blanco.

Y que es lo que nos responde google:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Server: GWS/2.1
Content-Length: 4289
Date: Sat, 04 Nov 2006 21:01:23 GMT

{A partir de aqui nos manda el documento no lo pongo porque aqui se veria mal}

La primera linea nos indica el código de la respuesta 200 para OK, 404 para no encontrado, 302 para dirigirnos a otro lado, etc ... Las otras nos indican el tipo de documento que nos manda o la longitud, entre otras cosas.

Ahora vamos con otras preguntas que hiciste:

Empezado por Al

AuthRetries. Ésta se me hace que la voy a necesitar para el ingreso de usuarios.

El protocolo http cuenta con un sistema de autenticación muy básico, que codifica la contraseña en base64. Quizá lo habrás visto alguna vez al intentar entrar en una pagina protegida muestra un dialogo para introducir el nombre de usuario y contraseña. Este sistema se uso mucho, aunque ahora la mayoría de las paginas utilizan su propio sistema de autenticación contra una base de datos usando un formulario y por ejemplo php, quedando este sistema bastante en desuso. Si la pagina a la que quieres entrar usan un formulario lo mas seguro es que no use este método de autenticación.

Empezado por Al

HandleRedirects. Esto me suena a cuando quiero entrar a una página y el navegador me lleva a otra, a veces de forma temporal para decirme que he ganado 50 millones de dólares y churradas similares.

Esto hace que si recibe como respuesta códigos como el 302 pidiendo que se dirija a otra dirección le haga caso y vaya, como ya dijo roman esto puede ser necesario para entrar en alguna pagina.

Bueno, creo que ya llego por ahora, aunque si tienes duda por algo o quieres meterte mas en profundidad en algún tema, tu solo dilo Porque ya sabes "que no tengo otra cosa que hacer"

[[seoane]]

Bueno, mientras no me aclaro con las "Expresiones regulares" sigo haciendo pruebas usando la función Pos de toda la vida . Aquí os dejo un juguetito, que se conecta al club delphi con tu nombre de usuario y contraseña, y comprueba si tienes mensajes sin leer. Puedes indicarle que haga la comprobación automáticamente cada 5 minutos y te avise con un pitido si hay mensaje nuevos. Para que esto funcione después de leer los mensajes hay que usar la opción de los foros "Marcar Foros Como Leídos", o de lo contrario seguirá viendolos como mensajes nuevos.

Lo dicho, es solo un juguete, para entretenerse mientras no nos metemos mas a fondo en el tema. Espero que este hilo no decaiga ...

[[Al González]]

¡Hola a todos!

Gracias por esa herramienta Domingo. Será muy interesante echarle un vistazo.

Actualizo el caso:

--------------------------------------------------------------------------
Prueba del componente TIdHTTP
Informe #1

Cargué en un navegador la página dada por la URL https://login.yahoo.com/config/mail?.intl=us, la cual es el punto de entrada al correo electrónico de Yahoo para cuentas de Estados Unidos. Esta página solicita los típicos nombre de usuario y contraseña de cualquier sistema de correo. Tomé su código fuente HTML guardándolo localmente como CorreoYahoo.htm. Al explorar su contenido con el bloc de notas, encontré que, como habría de esperarse, el método de envío de datos que utiliza es el Post:

<form method="post"...

Como ya sabemos, cuando el método es Get, los datos de captura son enviados al servidor Web como parte de la cadena URL; mientras que con el método Post, los datos son enviados de forma interna o “no visible”.

Me despertó curiosidad el saber cómo se comportaría la página y el servidor de Yahoo, si cambiara la palabra post por get. Lo hice y guardé el archivo como CorreoYahooGet.htm. Al ejecutar esa página Web, capturando la clave de usuario y contraseña que solicita, vi como estos dos datos aparecieron, junto con otros valores, en la barra de direcciones del navegador (como parámetros en la URL), lo cual era de esperarse. Lo interesante fue ver que el sistema de corro de Yahoo permitió el ingreso, a pesar de haber enviado los datos de esta manera.

Me llamó la atención otro detalle de la línea

<form method="post" action="https://login.yahoo.com/config/login?"

Entiendo que el atributo Action de la etiqueta Form indica la URL que el sistema deberá ejecutar al someter (submit) los datos, y que el signo de interrogación (“?”) se utiliza para dar inicio a los parámetros enviados en la misma URL cuando se utiliza el método Get. Mi pregunta entonces es ¿por qué aparece ahí el signo de interrogación si el método que utiliza la página es Post y no Get?

Sobre el útilmente sobrecargado método TIdHTTP.Post, la documentación dice algo que me pareció lógico y a la vez interesante:

When ASource is a TStrings instance, Post will replace all occurrences of
the End-Of-Line (EOL) character in ASource with the value '&' prior to
transfer to the HTTP server. When ASource is a TStream instance, no
preprocessing of the stream content is performed.

El símbolo ampersand (“&”) se utiliza para separar los parámetros entre sí en la URL cuando se utiliza el método Get. Es útil que cuando los parámetros son proporcionados como una lista TStrings, el método Post haga la sustitución de saltos de línea por dicho símbolo. Cuando los parámetros son indicados mediante un flujo TStream, éste es tomado tal cual esté, por lo que deberá contener ya los separadores & que sean necesarios.

De ahí que Tefots, incluya tales símbolos en el ejemplo que tan amablemente nos proporciona en el mensaje 12. Pero coincido con Román en que resulta más práctico usar una lista TStrings (el método TIdHTTP.Post también acepta ese formato). Por cierto, recuerdo haber visto un par de muy acertadas intervenciones de Román en este hilo, pero ya no están aquí. ¿Alguna razón especial por la que hayan desaparecido?

El siguiente es el código fuente de la prueba inicial:

Código Delphi [-]
procedure TForm1.Button1Click(Sender: TObject);
Var
  Parametros :TStringList;
begin
  Parametros := TStringList.Create;

  Try
    Parametros.Add ('login=debefuncionar');
    Parametros.Add ('passwd=xxxxxxxxxxxxx');

    Try
      Memo1.Text := IdHTTP1.Post ('https://login.yahoo.com/config/login?',
        Parametros);
    Except
      On E :Exception Do
        ShowMessage (E.Message);
    End;
  Finally
    Parametros.Free;
  End;
end;

La llamada al método IdHTTP1.Post me arroja una excepción EIdIOHandlerPropInvalid con el mensaje «IOHandler value is not valid».

Debe considerarse lo siguiente:

La URL comienza con https y no http. Cuando el protocolo es HTTPS, el componente TIdHTTP exige el uso de un componente adicional TIdSSLIOHandlerSocket asignado a su propiedad IOHandler, como puede observarse en este extracto del código de IDHTTP.pas (Delphi 7):

Código Delphi [-]
if AnsiSameText(URL.Protocol, 'HTTPS') then
begin
  // Just check can we do SSL
  if not Assigned(IOHandler) or (not (IOHandler is TIdSSLIOHandlerSocket)) then
    raise EIdIOHandlerPropInvalid.Create(RSIOHandlerPropInvalid)

Esto es algo importante a considerar, ahora que suelen verse en la Red muchos sitios que son «https://…».

Para cumplir con este requisito, hago uso de un componente TIdSSLIOHandlerSocket. Aún cuando los sitios a los que deseo acceder después de este aprendizaje sean de protocolo HTTP y no HTTPS, me interesa lograr hacer pruebas exitosas con HTTPS también. Aclaro que la excepción elevada que menciono ocurre por otras causas.

Depurando paso a paso el código de las unidades involucradas (con la opción Use Debug DCUs, que permite que uno pueda meterse hasta la cocina), encontré que la causa de este error se origina en el hecho de que la función Load de la unidad IdSSLOpenSSLHeaders.pas no logra cargar correctamente algunas DLLs.

Según este enlace de Borland:
http://support.borland.com/entry.jsp...externalID=406, se requiere un software llamado OpenSSL, específicamente los archivos libeay32.dll y ssleay32.dll para poder usar los componentes Indy con SSL (Secure Socket Layer), que es la especificación utilizada por una página HTTPS.

El sitio oficial de OpenSSL es http://www.openssl.org/, sin embargo no encontré en él un instalador que proporcione de manera fácil las dos DLLs que necesito. Así que descargué OpenSSL 0.9.8d para Win32 del sitio http://www.slproweb.com/products/Win32OpenSSL.html y lo instalé.

Pero aún así la excepción mencionada sigue apareciendo al intentar hacer la llamada al método Post. Haciendo un examen más minucioso de la citada función Load, descubrí que las DLLs sí logran cargarse, más no las funciones IdSslCtxSetInfoCallback, IdSslX509StoreCtxGetAppData, IdSslSessionGetId, IdSslSessionGetIdCtx, IdSslCtxGetVersion, IdSslCtxSetOptions, IdSslX509GetNotBefore, IdSslX509GetNotAfter, iddes_set_odd_parity, iddes_set_key e iddes_ecb_encrypt, que probablemente pertenecen a esas DLLs.

Ante esto, sospecho que debo utilizar otra versión de OpenSSL (no la 0.9.8d) para conseguir que tales funciones se carguen correctamente y con ello poder utilizar el componente TIdHTTP con sitios que utilizan Secure Socket Layer (HTTPS).
--------------------------------------------------------------------------

Les agradezo de antemano su ayuda.

Un abrazo neófito.

Al González.

[[seoane]]

Empezado por Al González

Por cierto, recuerdo haber visto un par de muy acertadas intervenciones de Román en este hilo, pero ya no están aquí. ¿Alguna razón especial por la que hayan desaparecido?

A mi también me parecieron muy interesantes los argumentos de Roman. ¿Que habrá pasado?

[hach]

Hola Al
como dec, yo accedo a Gmail con indy y tambien tuve problemas con las versiones de libeay32.dll y ssleay32.dll
No recuerdo como pero logre dar con las versiones indicadas
uso delphi 7 con las indy que el trae... que versión serán? parece que 9.00.10
las versiones de dll que me funcionan son las de indy_OpenSSL096m
Si no las consigues te las paso

Saludos

Pablo

[[Crandel]]

Empezado por seoane

Aquí os dejo un juguetito, que se conecta al club delphi con tu nombre de usuario y contraseña, y comprueba si tienes mensajes sin leer.

Al fin me he dignado a usar tu código de acceso a paginas web con WinInet y he mirado el código del programa que escribiste.

He visto que repites varias veces la sentencia:

Código Delphi [-]
FreeAndNil(Respuesta);
Respuesta:= TStringStream.Create('');

Se reemplazar por esta para que quede mejor:

Código Delphi [-]
Respuesta.Size := 0;

[[seoane]]

Muy cierto Crandel, es mejor poner la propiedad size a cero. Por cierto, no comentas que te parece el resto del código.

PD: Aprovecho para preguntar ¿que le paso a este hilo? ¿se puede considerar muerto? ¿nadie mas saco algo en limpio?