Safari. Odd behavior with Javascript.

[iHateMacs]

Hi, On my website I have a log in page written in html. It has on it a very simple form with just two fields, userid & password and a login button at the bottom.

There are two ways you can log in...

1) Enter the user name and then the password. Press the enter key after inputting the password. An onChange will catch this and call up the javascript login() function which is embedded in the page.

2) Enter both user name and password and then click on the login button. Clicking on this button also calls the same login() function through <a href="javascript:login().....

The odd behaviour is, depending on how the login() function is called (method 1 or 2 above) it does different things.

What is it supposed to do, is to "encrypt" the password using an external md5 function then using window.location it will take the user to the next page with the user id & encrypted password passed to it as a query string.

This works fine when you CLICK on the login button. But, if you have pressed enter after the password, the new page does not get shown but the query string only (including an unencrypted password) is shown in the URL bar.

Please try it and see. www.wallfillers.com/trade password and username are both "mac".

I've just installed the latest Safari for 10.4.11 and it still does it. Firefox works properly. Also IE and Firefox on the PC work properly.

I cannot understand how a function can operate differently depending on where it's called from. (well I can think of a 100 reasons, but in THIS simple case I can't think of one especially as it works in other browsers.)

It's got me stumped

EDIT: I have just installed Safari 3.1.2 on Vista and that shows the same odd behaviour.

 

[angelwatt]

You shouldn't require JavaScript like, there's a number of people who don't have it enabled, like myself, so it blocks them from getting in. Also you should be using the action attribute in the form rather than calling JavaScript. Switching things to the md5 format should be done server side rather than by JavaScript. This would make your from much more accessible and would remove any JavaScript quirks that are browser dependent. I have ideas of why Safari is having issues, but I don't have the time at the moment to look at it in more detail, but the form should be redone in my opinion.

 

[SrWebDeveloper]

I could not agree more with angelwatt - the client side method of MD5 hashing made me shudder from a security aspect. I'd ditch the entire method and move the code server side just as suggested.

Okay, with that being said, here is some useful code for you to trap the event key properly across various browser platforms then call a function of your choice (such as MD5 hash creation) with a parameter passed to it (such as login password):

First, add this JavaScript function to your existing JS stuff:

function checkKeyPressed(evt, func, params) {
  evt = (evt) ? evt : (window.event) ? event : null;
  if (evt)
  {
    var charCode = (evt.charCode) ? evt.charCode :
                   ((evt.keyCode) ? evt.keyCode :
                   ((evt.which) ? evt.which : 0));
    if (charCode == 13) func(params);
  }    
}

Then in your HTML add this along with your current onChange:

onkeypress="checkKeyPressed(event, 'CreateMD5', document.loginform.password.value)

Obviously in the HTML replace 'CreateMD5' with the actual name of your function in md5.js that processes the MD5 string which I assume is the password. If this works, adapt your code so the same thing happens during the onChange event. All above is untested code, just some suggestions you are welcome to try if you must rely on client side coding for this.

-jim

PS:

What follows is an additional informal suggestion or two after reviewing your site login:

Make sure "tabindex" is set in proper order for all form elements so the user can tab and cycle through the form properly. As a final cosmetic touch users will appreciate it if you set focus to the user ID input field, so the cursor homes there conveniently on the page load:

function ForceFocus() {
	document.loginform.userid.focus();
	}

In body tag:

onLoad="setTimeout(ForceFocus,100);"

Be sure to use the setTimeout method, the slight delay in time fixes timing issues with some browsers, i.e. this works across all platforms compared to calling ForceFocus directly.

-jim

 

[iHateMacs]

Thank you both for your input.

There isn't a security issue really. The reason for the login is to stop non trade customers seeing the trade prices. A worse case scenario would be someone thinking they are paying too much Any credit card stuff is outsourced to another company with a secure server.

I will take on board suggestions from both of you. i.e. simplifying the client side process and the cosmetic/functional improvements.

 

[SrWebDeveloper]

RE: Server side coding --> We just offer the advice in good faith and as always with good intent.

Well, I've offered my advice on how to handle the event key client side and also the focus issue (cosmetic) so I'm outta here unless you have ?'s about my code suggestions. Take care!

-jim

 

[elppa]

Try looking at using the onsubmit event.

That will fire when the user submits the form, either by pressing enter on the keyboard or clicking the submit button.

 

[HomeBru Studios]

As an aside, it is my opinion that usernames and passwords should NOT be passed as a querystring, period. That in itself is begging for a security breach.

 

[SrWebDeveloper]

Try looking at using the onsubmit event.
That will fire when the user submits the form, either by pressing enter on the keyboard or clicking the submit button.

From my recollection, hitting the enter key requires one of the form fields to be selected, meaning focused, (except <textarea>) to submit the form in some browsers. It's more reliable to trap the event via onkey - it's universally supported, works across one or more forms and gives the developer full control. This is not to say onSubmit() won't help in simple setups like this one, so consider this a heads up about the limitations.

Great advice for the OP, however!!! It is worth a shot.

-jim