Karl said:
Here's a simple script I have pulled from various sources and wondered if
there was a way to improve it. First, if the type the wrong password, I
would like to redirect them to another login page to tell them to try again.
Second, I would like to figure otu a way to keep someone from just
bookmarking pages behind the main page to bypass the password. I know this
is nor perfect and there is nothing critical behind the password protected
pages, but just wanted to shore it up a bit.
Thanks!
function PasswordLogin()
{
document.location.href = document.formlogin.password.value + ".htm";
return false;
}
function CheckEnter(event)
{
var NS4 = (document.layers) ? true : false;
var code = 0;
if (NS4)
code = event.which;
else
code = event.keyCode;
if (code==13)
{
PasswordLogin();
event.returnValue = false;
}
}
Using document.layers to determine that the browser is Netscape 4 and then using
that information to determine whether to use event.which or event.keyCode is
what is called "browser detection" and although it is probably a safe choice in
this case, it's best to use "feature detection". That is, test for the feature
you want before using it, rather than basing your decision on some arbitrary
object or property you think is only available in a particular browser. In your
case, this would make your code:
<script type="text/javascript">
function checkEnter(e) {
var key;
if (e && e.which) {
key = e.which;
} else if (event.keyCode) {
key = event.keyCode;
}
if (key == 13) {
// alert(document.forms['formlogin'].elements['pwInput'].value);
window.location.href = document.forms['formlogin'].elements['pwInput'].value +
".htm";
}
return true;
}
</script>
<form name="formlogin">
<input type="password" name="pwInput" value="" onkeydown="return
checkEnter(event);">
</form>
There's no reason to create PasswordLogin(). There's no reason to set
event.returnValue, since if key == 13, you are navigated off the page, no
JavaScript should execute after you set window.location.href. Note also that
it's window.location.href. document.location works, but it is deprecated.
There is no way of preventing someone from bookmarking the target page and
simply returning to it later, bypassing your elaborate security system. You
could attempt to test document.referrer in the "secured" page and if it's not
your security form, redirect back to your security form. But disabling
JavaScript would resolve that problem fairly quickly. Not to mention, if they
have the "secured" page bookmarked, it would just be a matter of typing in the
filename they already know.
As many have said, the only way to secure something is on the server. If you run
apache, you can do this with .htaccess:
<FilesMatch ".+">
# meet any condition for any file
Satisfy Any
Order Deny,Allow
# Deny everybody
Deny from All
# Allow local LAN users without auth - can be omitted
Allow from 192.168
# file to obtain user data from, may be different on your system
AuthUserFile /usr/local/www/data/.htpasswd
AuthGroupFile /dev/null
AuthName "Information you want on the browser auth dialog"
AuthType Basic
Require valid-user
</FilesMatch>
# ran into a problem... allow from 192.168 was showing .ht* files
# this FilesMatch directive prevents that; there is a FilesMatch
# directive in httpd.conf, but the allow from 192.168 above seems to
# override it or something
<FilesMatch "^\.ht">
Order allow,deny
Deny from all
Satisfy All
</FilesMatch>
(just noticed I can probably trim that down to a single <FilesMatch> directive:
<FilesMatch "^[^\.ht]">, but since I haven't tested this I'd stick with what
I've got above, which I know works)
and .htpasswd:
# to create the first one
htpasswd -c /usr/local/www/data/.htpasswd myusername mypassword
# to add more
htpasswd -b /usr/local/www/data/.htpasswd someoneelse theirpassword
Documentation for doing authentication in Apache is available at <url:
http://httpd.apache.org/docs/howto/auth.html />
