Foro - Perl en Español

Ya encontré respuesta a vuestra desazón, señor.

He aquí los pormenores de lo que hice. Os cuéntolo con todos los vericuetos que mi cabeza logró atajar, y llegar, a una simple solución, pues, es bien sabido, que las cosas simples y llanas, más del gusto son, pues es más fácil para las entendederas apreciar sus más preciados detalles.

Espero que entendáis dicha explicación y que aprovechéis sus enseñanzas, para regocijo vuestro, presente y futuro.

Al principio, delante de vuestros escritos, parecióme que debería pedir pistas de qué es lo que realmente sucede, no sea que algún maquiavélico engendro oculto hiciese sus malas obras a escondidas, y a la vez, a la vista de todos nosotros.

Por ello, agregué la línea use LWP::Debug qw(+ -conns); al principio, para, cual espía infiltrado en las líneas del ejército contrario, nos chivase todo aquello que en él sucediese.

También, sustituí la línea $cookie_jar->save( $txt ); por una entrada autosave => 1, dentro del HTTP::Cookies->new, pues es más corto, y quizás, más seguro. Estamos diciendo que queremos que nos guarden las galletas al final del proceso.

La salida del print $cookie_jar; también la cambié por print $cookie_jar->as_string; pues es la forma correcta de ver el contenido, en texto, de la jarra de galletas.

Lancé el programa y este fue su discurso:

Código: Seleccionar todo

LWP::UserAgent::new: ()
LWP::UserAgent::request: ()
HTTP::Cookies::add_cookie_header: Checking www.gamesites200.com for cookies
HTTP::Cookies::add_cookie_header: Checking .gamesites200.com for cookies
HTTP::Cookies::add_cookie_header: Checking gamesites200.com for cookies
HTTP::Cookies::add_cookie_header: Checking .com for cookies
LWP::UserAgent::send_request: GET http://www.gamesites200.com/ultimaonline/in.php?id=862
LWP::UserAgent::_need_proxy: Not proxied
LWP::Protocol::http::request: ()
LWP::Protocol::collect: read 421 bytes
LWP::Protocol::collect: read 2479 bytes
HTTP::Cookies::extract_cookies: Set cookie PHPSESSID => c3e2ff170f45ad5718097ba4c8c991dc
LWP::UserAgent::request: Simple response: OK
Set-Cookie3: PHPSESSID=c3e2ff170f45ad5718097ba4c8c991dc; path="/"; domain=.gamesites200.com; path_spec; discard; version=0

Así que es cierto: la galleta la tenemos en nuestras manos, pero... ¿dónde está?

Código: Seleccionar todo

explorer@portatil:~/Documents/Desarrollo> cat cookie.txt
#LWP-Cookies-1.0

Toca estudiar, pues es un comportamiento extraño, dominado por fuerzas extrañas y que aún no acabamos de entender.

Entonces, recordé haber visto una nota especial en el libro sobre galletas que tenía abierto, titulado "HTTP::Cookies". En el capítulo sobre as_string, que es lo que yo usé antes, ponía una extraña advertencia: "si el conjuro se nombra con la palabra VERDAD, as_string devolverá todas las galletas salvo las que estén marcadas con el signo Discard".

Bueno, es una referencia a que no todas las galletas se devuelven. Ya tenemos una pista de que no todas las galletas son mostradas alguna vez. La nuestra, sí que tiene puesta la marca discard. ¿Qué significará?

Busqué por el mismo libro y llegué, unos capítulos más arriba, a la sección clear_temporary_cookies. Allí decía que eliminaba las cookies que no tuvieran campo de expiración o que tuvieran la marca discard, y, que tal como reza en el Gran Libro, página 2965, eso ha de ocurrir siempre que se acabe el proceso lanzado. Así que las sospechas se cumplieron: la galleta es borrada por nuestro propio programa porque está marcada así desde el principio.

Es claro que el trabajo de la cookie empieza y termina a lo largo de la duración del programa, lo mismo que la sesión de un humano delante de esa página. Mientras el programa esté funcionando, la cookie existirá. No hay más preocupaciones que el de dejar que HTTP::Cookies haga su trabajo.

Pero, en el caso de que deseéis conservar dicha galleta más allá de la ejecución de este vuestro programa, esta es la solución: agregar la entrada ignore_discard => 1, al new, e impedirá que el borrado ocurra. La galleta aparecerá en su jarra de galletas.



Con gusto departiremos, si ese es vuestro deseo, el que este descubrimiento tan sin igual nos depare en cuanto a disquisiciones y futuros problemas.

El funcionamiento normal es que las cookies correspondientes a un dominio se deben transmitir en la cabecera de petición GET, para que el servidor sepa que se trata de una sesión anterior.

¿Pero lo que quieres es conectarte al web como si no tuvieras cookies?

El proxy está haciendo su papel de intermediario entre vos y el servidor final. Como es una petición a un dominio conocido, LWP::UserAgent sabe que tiene que transmitir esas cookies en la petición, al proxy.

Si el servidor no te responde con la otra cookie... sospecho que sea debido a que ya ha almacenado la IP del proxy, y por lo tanto, ya no cuenta como IP nueva.

De todas formas, si quieres que se conecte sin cookies, lo único que tienes que hacerle a tu niño glotón es, al principio... quitarle la jarra de galletas. Y probar a dárselas más tarde.

Es decir: conéctate sin la jarra de galletas que tienes. Por ejemplo, una jarra de galletas en memoria (hay un ejemplo en HTTP::Cookies). Después de conectarte, activar la jarra de galletas en fichero.

De todas formas... todo este jaleo, ¿para qué? ¿por qué es importante esa página? ¿qué pretendes conseguir?

Pues si el sistema de voto depende de la IP del origen, poco se puede hacer. El sistema recordará la IP del votante, da igual que sea del proxy o la real. Un efecto perverso de este sistema de votación es que hay redes enteras que quedarían fuera del sistema de voto con tal de que vote uno de ellos. Por ejemplo, las empresas de cable suelen ofrecer IP locales a sus abonados, y todos ellos salen al exterior por unas pocas IP públicas. Bueno, pues basta que uno de ellos vote en un sistema como estos para que los otros 10.000 abonados ya no puedan hacer ni votar, ya que el sistema de voto siempre ve la misma IP (la del proxy).

De todas formas, sí que es posible averiguar la IP real del que hace la petición a través del proxy (va en la cabecera HTTP). En los sistemas tipo navegación anónima, sí que está oculta.

Puedo estar equivocado, naturalmente, pero para que el programa funcionara debería de utilizar todos -o una buena parte- de los proxy existentes, para que cada uno contase como un votante.

Tienes un par de dificultades más... en el formulario de la página de voto, hay un par de campos ocultos. Uno se llama 'hi' y el otro es uno de tipo submit que no tiene valor, pero está oculto. La otra dificultad es que el botón de submit que aparece en pantalla tiene un nombre aleatorio (jam, hiya, food, sendin, etc.) cada vez que solicitas el formulario).

Algo extraño me pasa, que no consigo hacerme con la cookie allowvote desde una máquina que no ha votado. Seguiré mirando, pero a lo mejor es tan tonto como crear esa cookie desde cero. De todas formas, si en el momento de sumar un voto se da cuenta de que es la misma IP, no lo tomará en cuenta. Ahí es donde entran en juego los proxies.