I see only one other solution but it depend on the type of authentication used. If it is basic authentication then you might use a specially crafted URL to log-in:

http://username:password@host.domain
[download]

A standard Apache server using basic authentication will accept this to authenticate a user rather than having the browser pop-up the "Username / login" dialog box. If it is a more sophisticated scheme that will not work.

If that doesn't work you can still PAR-package your WWW::Mechanize script (or slim it down as much as possible to have fewer dependencies) and give that to the user and let him run it to log in.

Somewhat OT

I fail to understand why your users can't use their own user names and passwords.

While I have an MPhil and have been lucky enoughht to work in mathematical research for over 10 years of my life, I have also worked at the lower skill level, showing people how to use websites, how to use a browser and what the component parts of a computer are.

Maybe I'm getting something wrong here but my attitude was if they couldn't follow the instructions given then there was at least something wrong with my understanding of where they were in their learning and I needed to correct that expectation to be able to help them further.

I've also worked as a software developer, sometimes with user contact. Again, if there was something wrong with the user's understanding then work was done to correct the way information was presented to enable and empower the user to gain understanding and the skill to make good decisions on their own.

I take it this is out of fashion in the world of user support these days?

Here's an idea - I'm not sure I would actually recommend DOING this, for security reasons, but it will do what you have asked for...

Most web-based logins use a session id, which is stored on the client side (browser) as a cookie. People go to much effort to generate unique session ids, since chaos will ensue if multiple people have, for example, access to the same shopping cart at the same time.

But in your case, you could create one session, with a session ID of "1", and write this out to every client. This makes EVERYBODY look like "user 1" to the server.

As long as the users do "read only" type operations, this may work. If they can read and write - then you may have a lot of problems.

Note that most cross-site-scripting attacks basically involve a bad-guy stealing someone else's session id, and thus taking over their identity. So...

Also, keep in mind that over the years, programmers have tried really hard to develop idiot-proof applications, but the forces of evolution keep producing better idiots...

Not strictly on topic but....

Once upon a time I had a similar problem. When in a polite mood I referred to certain end-users as "novice" and in less polite moods as "severely challenged". :)

Usernames/passwords are the reason my hair line moved back an inch. Part of the problem is that people believe they are gifted typists... they aren't. A technique I used successfully time and time again was this:

First I had them get a pen and paper and write down the username and password. Then I instructed the end-user to position their keyboard rotated 180 degrees. Then I tell them to carefully enter the user/pass and say aloud each letter/number as they press the key. With the keyboard upside down they are forced to actually focus and hunt for each key. Then by saying it aloud the odds they are getting it correct are increased.

Even with all that I still sometimes had to have them go get a neighbor...