Note: vastly simplified.

package MyUA;
use base 'LWP::UserAgent';
{
  my $user;
  my $pass;

  sub set_creds { $user = shift; $pass = shift; }
  sub get_basic_credentials { ($user, $pass) }
}
[download]

get_basic_credentials() is called by the GET/POST/FOO methods when challenged (perhaps more often, you may need to verify this). I use it to read passwords from a config file, prompt from a terminal w/o echoing, and other times that I need to access restricted sites.

Update: credentials(), afaict, takes 4 parameters, not two. Perhaps that is the root of the reason it isn't working. Reached for my favorite hammer when a screwdriver was already provided.

Update 2: Per almut in Re^4: Better Solution To WWW::Mechanize Basic Authentication, I stand corrected. Two parameter version is quite correct.

credentials(), afaict, takes 4 parameters, not two.

Later versions also do support two parameters. From the Changes file:

1.20   Sat Aug 19 09:09:08 EDT 2006

        [ENHANCEMENTS]
        * Added new two-argument form of credentials() method.
          $mech->credentials($username, $password);
          That provides simpler visiting of password-protected
          resources in the vast majority of cases and still
          allows the other cases to be supported. (Peter Scott)
[download]

Thanks for the correction. I s'pose I should update my distribution one of these years. :-)

--MidLifeXis

MidLifeXis,
Yes, get_basic_credentials() is called but, unless overidden, just pulls the information from credentials(). As it turns out, WWW::Mechanize does overide the method but just marginally.

None of that changes why it is isn't working. In other words, calling $mech->credentials() before calling $mech->submit() should "just work" but it doesn't.

Are you suggesting subclassing WWW::Mechanize to hard code the values on a per-instance basis? That seems further from my objective (work within the confines of WWW::Mechanize).

Cheers - L~R

I was unfamiliar with the credentials() function, and had always grabbed the get_basic_credentials() call to do my stuff - blame it on my not reading carefully. :-/

I have had that type of an error (I won't say exact, because I don't remember it exactly) happen when no_proxy wasn't working the way that I thought, and an internal site was hitting the outside proxy. Since the outer proxy didn't recognize the internal username and password, and could not have even connected to the internal server, I was hosed from the start.

I seem to remember there being a way to force verbose output, and using that to find out what was actually happening.

--MidLifeXis