$n->set_visible( $user, $password );
[download]

I've found that set_visible isn't always reliable; sometimes there are other fields or weird javascripty widgets that mess it up. I find it's almost always better to specify the fields by name. So assuming the fields are called 'username' and 'password', try something like:

$n->set_fields( username => $user, password => $password );
[download]

Unfortunately the names are not that easy. Example:

Read more... (103 Bytes)
and I don't want to have those complicated names in my script. Especially not because they might choose to change them!

Fortunately set_visible is not the problem as the data really goes to the expected fields as the network analysis reveald.

---

s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
+.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e

I've recently gotten into WWW::Mechanize... i would try this instead...

#!/usr/bin/perl
use strict;
use warnings;
use WWW::Mechanize;

my $user= 'XXXX@spamgourmet.com';
my $password= 'XXXX';

#maybe need cookies?
my $n=WWW::Mechanize->new(cookie_jar => {});

$n->get( q(http://www.nintendo-europe.com/NOE/de/DE/logout/index.jsp?D
+PSLogout=true) );
$n->form_name('login');
$n->set_visible( $user, $password );

#specify form to submit
$n->submit_form(form_name => 'login');

print $n->content()
[download]

just by quickly looking at it... set_visible might be your best bet since those fields don't have specific names. And as far as I can tell... those are the first two (non-hidden) fields in that form.

If it still doesn't work, try debugging by taking a look at $n->forms(). That should return an object of all of the form elements that mech sees and give you a better idea what to use for the fields. hope this helps.

Maybe it would help to post the data your script is sending as well as the data your browser is sending, or even better, to compare the data of both yourself, and then to determine what the difference is, and where it might stem from. Maybe the website uses Javascript, for example.

I already tried to analyze the data by myself and found differences. But I have absolutely no clue why the difference is there.

JavaScript yes-but...

Yes, they use JavaScript and there is an onclick.handler for the login.

But, you can log in without JavaScript and I did that using the browser.

I didn't want to dump the data here unless it's necessary. I think I will first try the SHell-approach...

---

s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
+.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e

Two things I'd recommend you try are HTTP::Recorder and Ethereal. More on both may be found here.

HTH,

Thanks, planetscape! I'm using ethereal since the last millenium ;-) and used it to find out that there is something different as stated above.

But HTTP::Recorder is new to me! Very helpful it seems. I will test it.

Currently I have problems installing WWW::Mechanize::Shell and so I'm not gone any further in solving my "problem".

---

s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
+.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e

Don't forget that HTTP::Recorder's author is leira, a PerlMonk (and an extremely helpful one, too!).

I had a few issues getting things up and running using WinXP SP2, Cygwin, and HTTP::Proxy, so if you need anything else, run it by me and I'll see if I can help further. :-)

planetscape