My signature is the way it is because I like to note the fact that downvotes are a welcome factor when they are given when appropriate. It's also a memo to those who downvote without reason: if you can't give me a reason for the downvote, then I take the negative vote as just that: a physical vote with no thought on the voter's side of things. If however, I am told why I was knocked down, I know the voter spent time analyzing my post. I can take it as constructive critisism and can fix things so that the post will provide a better response for the next reader that stumbles upon it.

Perhaps just getting users to /msg you and then sending them a new generated password.

Yes, that's fine if all I needed to do was verify that a new player is an existing PerlMonks member. This method would not allow me to later access the site with their login (programatically of course). For example, if and when I add a feature that allows users to check their private messages, I would require the login cookie which effectively requires a username/password combo to first be sent to the site.

Besides, how were you going to authenticate their user/pass in the first place - login to perlmonks as them?

Essentially... yes. To be precise, I'll be executing more or less the following code for now. In the future, the value of $xml->{'_headers'}->{'set-cookie'} may need to be kept (only in memory) for the duration of a session in order to allow successive hits to the site's xml feeds as a logged in user. Note that the cookie wouldn't even be stored in a database. Only in memory from the point in time when a user logs into the MUD to the time they logout.

 my $username = user_input('Username: ');
 my $password = user_input('Password: ');

 my $ua = new LWP::UserAgent;
 my $xml = $ua->get(
  'http://www.perlmonks.org/index.pl?node_id=227820&' .
  'op=login&user=' . uri_escape($username) . '&passwd=' .
  uri_escape($password)
 );
 undef $password; # deny access to $password later on
 deny_access('User authentication failed.')
  unless grep { /set\-cookie/i } keys %{$xml->{_headers}};
[download]

Thanks :)

If the above content is missing any vital points or you feel that any of the information is misleading, incorrect or irrelevant, please feel free to downvote the post. At the same time, please reply to this node or /msg me to inform me as to what is wrong with the post, so that I may update the node to the best of my ability.

if and when I add a feature that allows users to check their private messages, I would require the login cookie which effectively requires a username/password combo to first be sent to the site.

You are a much braver person than I.

Personally I wouldn't want to be responsible for the account information of everyone playing the game. I'm sure perlmonks accounts aren't worth much to most people but this is a troll's wet dream. I assume you'd be sending the passwords from your site to Perlmonks in plain text? I hope you at least trust every system between you and perlmonks (including your own).

How these things go uncriticized on a web development site are beyond me.

I assume you'd be sending the passwords from your site to Perlmonks in plain text?

Yes, the same way that browsers pass the login info to the server when users login to the site :) Though passing the password in plain text would only happen once in order to grab the cookie. Then the cookie would be sent instead. A little more secure. Not perfect, but good enough I say.

How these things go uncriticized on a web development site are beyond me.

They don't go uncriticized. Some people don't like it, some don't really care, and some figure it's great if it allows more functionality to something. I live with the complaints :)

---

If the above content is missing any vital points or you feel that any of the information is misleading, incorrect or irrelevant, please feel free to downvote the post. At the same time, please reply to this node or /msg me to inform me as to what is wrong with the post, so that I may update the node to the best of my ability.