I frequently use the server's natural password protection scheme. However,
sometimes there are reasons to use CF (or another lang) to do it, so in that
instance I have a login page that validates the user against a database and
sets a cookie if validation passes. The scheme would be something like
this:
login.cfm - receives username and password, checks them, if check passes
sets cookie
validate.cfm - called by cfinclude on every page that is protected
<cfif not #isdefined('cookie.USERID')#>
<cflocation url="errorpage.cfm">
</cfif>
This way the actual content of the secret pages can not be displayed if the
user hasn't passed authorization.
***************************************
Jonathan R. Karlen
Karlen Internet Solutions
Web Site and Application Development
[EMAIL PROTECTED]
http://www.karlen.com
-----Original Message-----
From: Andrew Barnett [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, July 26, 2000 8:26 AM
To: [EMAIL PROTECTED]
Subject: Re: [wwwac] password protection
MElissa GOuld wrote:
<snip>
>can anyone of you point me to a good script for a password protection
>code?
<snip>
Just my $0.02 -
I've been following the thread regarding password protecting web
content, and all the schemes that involve randomly generated URLS
(such as http://domain.com/21323475/foo.html) seem a trifle
cumbersome. This is especially true if they involve manual renaming
of directories on the server (even if through cron or other script).
>similarly, once person A has code he then knows the URL for the
>secret
>page, right? and nothing can stop him simply giving that URL to
>anyone
>on earth, right? can that keep changing too????
Most web servers can be set up so a secret page is always password
protected. I believe most modern web servers allow you to set
authentication on an entire directory hierarchy. Take Apache, for
example. If I password protect the http://domain.com/members/
directory, *everything* below that directory is password protected
unless protection is explicitly turned off. So
http://domain.com/members/images/ is also protected with no further
action on my part, even if someone directly types in a URL for this
directory. I *believe* this is how IIS also works, although I honestly
have never tried. The problem with this is it requires human
intervention every time someone signs up for your service. If you
have a small set of users (systems administrators, for example), then
this is the quick and easy way to do things. So unless your users
share passwords, this would do what you require.
I tend to favor the PHP/mod_perl approach for large public sites with
an extensive user-base. In PHP it's quite simple, you create an include
file (called auth.inc for example) that does all of the authentication
work. Users may be authenticated however you choose -- to database,
disk file, or phase of the moon. Any PHP script that I want password
protected simply includes the auth.inc file. Since I usually set up
the auth.inc file to use sessions or cookies to store an encrypted
version of the authentication, the user only needs to log in once to
have access to protected files. This also allows me the flexibility of
having multiple levels of access -- supervisor passwords, for example.
Another nifty thing about this is that it does not require any special
HTTP return codes to generate the authentication request (like 404
Access Denied) -- I can set this up to use a plain HTML form.
I'll admit to being curious about the method suggested by Steve Manes
in a previous post, involving an automatic hash of session data being
stored in the URL. Although it looks suspiciously like manual
URL-munging, from what he says it is fast and has the benefit of not
needing cookies. It sounds similar to one of the session flavors of
PHP4 that mangles URLs rather than using cookies.
OK, so that wasn't $0.02, more like $0.42. Sorry.
--
======================================================================
Andrew Barnett PO Box 701
Data Clarity, Inc. Abington, PA 19001
[EMAIL PROTECTED] tel (877)496-3527
http://www.dataclarity.net/ fax (801)382-1525
======================================================================
## The World Wide Web Artists' Consortium --- http://www.wwwac.org/ ##
## To Unsubscribe, send an e-mail to: [EMAIL PROTECTED] ##
------------------------------------------------------------------------------
Archives: http://www.mail-archive.com/[email protected]/
To Unsubscribe visit
http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a
message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
