Description: I have been attempting to write a script which will extract data from an email and post it into a secure form. The email extractor is currently working and writing the data to a "|" delimited file which the account creation script reads from. The account creation script correctly reads that file and splits them into individual variables (tested with "print $var" for each). With this data, the script then uses WWW::Mechanize to login to the secure site and passes the cookies to LWP (since the site uses javascript for navigation). LWP then writes new POST headers to simulate submitting the form. While this does create a new user, none of the data fields (name, phone, etc.) are populated, even though I include them.

My Code:

Code

#!/usr/bin/perl use strict; use WWW::Mechanize; use HTTP::Cookies; use LWP::UserAgent; use LWP::Simple;

after your form post. You need to install Crypt::SSLeay to use https addresses with LWP::UserAgent. If you don't have it installed, then the above code will tell you that.

Otherwise, maybe it's the fact that you get redirected when you go to https://www.storesonlinepro.com/account, then the form being submitted doesn't specify an action so it goes to that same redirected address? I'm just not sure how LWP handles that.

The for loop ought to terminate right before : print "Writing Event Log\n"; but it seems I accidentally removed that with the other extraneous comments that were there. It terminates correctly in the original script, I assure you. I'm sorry for my inaccurate transcription.

As for the three posts, I'm having problems with the second two. The first one doesn't submit new data as it retrieves the value for $formnumber, a number which changes each session. The second post ought to submit the client's name and other info, but doesn't. The third post set which groups the client belongs to and ought to set their password. It sets groups correctly, but neither the password nor the email values seem to stick.

I don't suspect a misfunction of the CGI because I can manually enter the information using the website via my browser.

Indeed. Stupid question, but are you sure you've got the field names right for the misbehaving fields?

I've run across javascripted pages that, when confirming things such as email and password strength, actually write the confirmed values to hidden form fields and then those fields are the ones used in the CGI. Anything like that going on?

Unfortunatly, as it is a client's account, I am not at liberty to divulge the account/password. I'm sorry for how inconvenient this makes things.

I'm pretty sure I got all the fields right since I based them off of data taken from the TamperData Firefox extension (Included below) Because of this, though, I'm pretty sure I got all the fields, even the hidden ones.

Well, I know that there are no errors in transmittion because it populated the $content variable. I also know that it correctly recieves the account_id field because it pulls up the correct page. I honestly have no idea what account_changed does. It has no effect when I use tamperdata to remove it when I use the browser, nor does it effect the outcome of the script when it is not included. But yes, the values in the second post are not sticking. I had hoped it was just a stupid mistake in my code, but.. Thank you

An excellent point. Unfortunately, even with it corrected it does not alter the script's end result. I'm beginning to think "account_changed" is for auditing purposes as it seems to hold no sway in the submission of data. v__v