Firstly, I’ll tell you what I’m not showing you.

• I’m not showing you that this claims to be an XHTML page, despite the invalid element nesting that makes Firebug mark many of the elements of the DOM in its faded “what the hell?” style
• I’m not showing you that the same JavaScript function is included twice, for no useful purpose.

In fact, I’m showing you a cleaned-up snippet that demonstrates the behaviour of the login form while sparing you some of the worst syntax of the original.

The login form

The login form appears on the page as two text fields, for username and password, and a “Connect” button, as you’d expect. What is not apparent until you examine the source, is that the username and password are in different forms, which I believe is the key to this trick.

 <form name="login"
       action="sm_login.fcc"
       method="post"
       onsubmit="connect(); return false;">
    <input type=hidden name=SMAUTHREASON value="0">
    <input type=hidden name=SMAGENTNAME value="IoqEFNY64K">
    <input type=hidden name=POSTPRESERVATIONDATA value="">
    <input type=hidden name="SMENC" value="ISO-8859-1">
    <input type=hidden name="SMLOCALE" value="US-EN">
    <input type="hidden" name="PASSWORD" value="">
    <input type="hidden" name="lang" value="">
    Username: <input type="text" name="USER" maxlength="8" size="23">
  </form>
  <form name="pwd"
       onsubmit="connect(); return false;"
       method="post"
       action="">
    Password: <input type="password" name="tpep" size="23">
  </form>
  <input type="button" value=" Connect " onclick="javascript:connect()">

So here we have two forms. One is the real login form, login, but what should have been a password text field has been made hidden. A second form, called pwd, has been used to hold a new password text field. The “Connect” button doesn’t belong to either form, but calls a global connect() function, just as the other two forms do.

connect() function

Both forms run submissions through a piece of JavaScript:

function connect() {
  if (document.login.USER.value == "") {
    alert('Enter your user name');
    document.login.USER.focus();
  } else {
    if (document.pwd.tpep.value == "") {
      document.pwd.tpep.focus();
    } else {
      document.login.PASSWORD.value = document.pwd.tpep.value;
      document.login.lang.value = document.pwd.lang.value;
      document.pwd.tpep.value='';
      document.login.submit();
    }
  }
}

This little beauty does some standard checking that neither the username or password are blank, but then it copies the password field that we typed into the other form’s hidden field, blanks the visible password, and then forces submission of the login form.

This function can’t just return true or false to allow or stop the normal submission event, because it might have been invoked from the second form, “pwd”, if I pressed Enter after typing my password.

Greasemonkeying this baby

I routinely use Greasemonkey to make our intranet even vaguely usable, which for me means making sure that text isn’t too small for me to read, correcting structural defects that Internet Explorer ignores but which break the layout on Firefox, and adding functionality to applications.

Unfortunately, the structure of the real page that contains this snippet is ugly enough that I’ve so far failed to fix it. What I need to do is to defang the connect() function and put the password field in the first form, but I’m going to have to rewrite quite a chunk of the login page to achieve this.

While considering how to do it, however, I was playing around in Firebug, and quite by accident managed to rewrite the form enough to get Firefox to remember the password, and then insert it in the real thing. Bizarre, but satisfying