It doesn't just validate the form as the name suggests, but encodes the password in base64, copies that to a hidden field of the form, removes the plain text entry of the password (I don't understand the paranoia - they are using ssl after all) and does some md5 magic.

Thank you for the suggestion. I also considered that idea of mimicing the validate_form's behavior in my code. But, even then, hitting the OnSubmit Javascript method in the form is unavoidable before POSTing. Is there any way to bypass this OnSubmit at the client side and send the values directly to the server?

Of course you can POST any data you like to a HTTP server, with LWP::UserAgent for example, and I'm quite sure WWW::Mechanize allows that as well. Your perl script doesn't hit any button, it just sends data to the server.

All a server does is send data to a user agent - and that data has the form of HTML with embedded javascript - it doesn' t have any kind of control over how the user agent interprets the data.

So all your script has to do is to send the same data as a web browser would do.

If you don't want a general solution, but only one that works for you, there might be shortcut. If you look at that function again:

function validate_form(form)
{
  if ( form.user_id.value == "" || form.password.value == "" )
  {
    alert( "Enter a username and password." );
    return false;
  }
  //short-cut if challenge/response is disabled.
  if ( !_useChallenge )
  {
    form.encoded_pw.value = base64encode( form.password.value );
    form.encoded_pw_unicode.value = b64_unicode( form.password.value )
+;
    form.password.value =  "";
    return true;
  }
  ...
}
[download]

There seems to be a chance that the system accepts login without challenge/response, so all you have to do is to login once manually, and record the the values that are stored in form.encoded_pw_unicode and in the username field, and then uses this data each time you want to log in.

I think ragas wants to automate a login process with a perl client, and can't control the server side - that's why it is impossible to avoid dealing with javascript.

All those explanations about web 2.0 , js and perl (not PERL, btw) are fine, but they don't help with the task at hand.

I hoped that i could answer without any code snippets and yes perhaps I did extrapolate too far...


<form method="POST" action="in(cgiurl)" name=form1 onSubmit="return Se
+tPass();">
[download]


is the basic line...

in this case, set pass actually sets the cookie, however, if the cookie is wrong, the script won't work... lot's more could be done there... by JS... I let the perl script send the users to the templated login page... so a simple link from a public page or inline on that public page... it will work the same if you submit action to the actual address of your script. basically, your script has to deal with the info it gets... there is a data parsing function ... getdata ... called by the main() function

if($usecgi){
use CGI;
$query = new CGI;
@names = $query->param;
foreach $i (@names){
  $in{$i} = $query->param("$i");
  }
}
else{
# Read in text
  if ($ENV{'REQUEST_METHOD'} eq "GET") {
    $in = $ENV{'QUERY_STRING'};
  } elsif ($ENV{'REQUEST_METHOD'} eq "POST") {
    for ($i = 0; $i < $ENV{'CONTENT_LENGTH'}; $i++) {
      $in .= getc;
    }
  } 

#.... followed by more code for parsing, splitting and assigning the n
+ew variables
[download]


this sample script parses the POST data if any... here there are 2 conditions which call the login template...



($in{'command'} eq 'login')&&(&Login);
($in{'command'} eq '')&&(&Login);
#all require password below
&GetLogin;
...
# passing thru Get login allows access to more program functions and a
+dditional pages. the login page actually calls the next page... via h
+idden form field
[download]



I don't see his code doing any of that. I see him trying to set up the page and sending them off to the secret content without having the server do any checking via perl.
If it successfully presents the login page, then it will finally need to pass thru the login page to the goodies behind that. for security reasons, I can see why the javascript shoul disguise the username and password and then potentially send the data either as the cookie request or via plain text... with or without the benefits of ssl.

I previously provided the basic hint to look at Javascript and let it do what it does and allow perl to do what it does...
in my case, setPass() does the combination of verifying that user has filled both fields and alerting if otherwise... it then creates a hash and stores the cookies locally... when setpass is satisfied, it returns true. otherwise it returns false. and the action fails. and the hidden field provides the (CGI)action "manage" which can only be reached by passing thru the GetLogin/Cookie retrieval process. and continuing to have a cookie until the session expires. Any failures should take youu back to the login screen.


sub GetCookies{
$cookies = $ENV{'HTTP_COOKIE'};
@allcookies = split(/;\s*/,$cookies);
foreach $i (@allcookies){
  ($name,$value) = split(/\s*=\s*/,$i);
  $cookie{$name}=$value;
  }
}
[download]



the perl script then knows how to extract and check the cookies , and finally, it checks the retrieved against the stored password and username


sub GetLogin{
&GetCookies;
$in{'UserName'} = $cookie{'UserName'};
$in{'PassWord'} = $cookie{'PassWord'};
if(!$in{'UserName'}){
&PageOut('t_login.htm');
exit;
#back where you started, though the Javascript  sees that it never com
+es here
}
else{
(($in{'UserName'} ne $username)||(($in{'PassWord'} ne $password)))&&(&
+PError("Error. Invalid username or password"));
#here we need to check the final results after parsing the cookie info
+ and retrieving matches in the db of variables...  we have no choice 
+but to return a server error message.
}
}
[download]



one might substitute a Mechanized page for a template... so on the first call to the script, you build the page, and the second call to the script, checks the returned data...

essentially, there is a shared variable space @in{''} which need be passed between the page (javascript) and the server (perl)

I certainly will continue to maintain that "the old way" is to ignore javascript and just continue to pass the variables back to the serverside parsing and keep returning the errors that way. (ERRORS in actual password or login are unavoidably handled this way.)

Yes, Perfect. You have put it short and sweet. I am trying to build a perl client for automating the login process and the Javascript and server side logic is not in my control. So I am looking for alternatives.