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.