Perl Server Side CGI Scripting Forum

form name="signup_form" method="post" action="http://www.example.com/scripts/addlead.pl">
<input type="hidden" name="meta_web_form_id" value="1062531085">
<input type="hidden" name="meta_split_id" value="">
<input type="hidden" name="unit" value="desk-top-bucks">
<input type="hidden" name="redirect" value="http://www.example.net/1A6dfZ.php"

Do you have a clue how he makes that work? Does the writing of the passwd file is done when the submit button is clicked or when the perl script redirects the client back to the php page?

Thanks

Rick

I just got a reply from Aweber and they told me that it's not coming from their perl script!

In other words, when the client fills out the form, the info (including the username and password) may go to Aweber's autorepsonder perl script and then the info entered by the client comes back in his email so that he can remember the username and password he has chosen for his login info.

This still doesn't tell me how the form's username and password got inserted into the Htpasswd file!

Logically, if it's not coming from the perl then it must come from the php page. It's either when the form goes to Aweber or when the client is being redirected back to the guy's website.

I just out the form and notice that when the form goes to Aweber, it's redirected back to that php page but the URL becomes filles with the info filled in the form like this

http://www.example.com/1A6dfZ.php?custom%20password=passwordtest&custom%20username=usernametest&from=joe%40joe%2ecom

Looks like the php page can collect this form info and store it into the Htpasswd file somehow?

Any idea how it does that?

Rick

The bottom line is that when someone chooses a name and password, if you are using a scripted user login system, you simply store the user name and password in an encrypted form in a database.

A www authentication scheme is a whole different matter, as this operates on the server system level. This indeed can be done - but it means allowing the script to edit your .htpasswd file. IMO this is a Bad Idea because only root or the direct domain owner should have perms to edit .htaccess or .htpasswd. But it is done, and it is done a lot.

Automatically logging in:

For a scripted system, this is easy. You set a session-only cookie storing the user's login name and the password in encrypted form in the user's browser. Read the cookie first on request, if a user and pass is not found, look for input and read the login input from a form, and if a matching value is found in the database for one or the other, log them into services. If no matching entry is found, return a please log in page.

For www authentication, this is a bit more tricky, and may not evem be possible any more. I can't recall the syntax and I seem to remember something has changed a few years back, but for a while there it was possible to send remote www authentication via a typical query string by doing something like

http://www.example.com/secured_directory/?user=username@domain.com&pass=password