Umm. You sound confusing to me. I have messed around with JavaScript
onUnloads to kill sessions, but you have to use a framed environment there
or else for every page change, the unload will fire off.
You can do funny things to track user sessions, but the best way is to have
a really short timeout value and use either session or client vars. If you
want to use client vars but want a timeout shorter than 2.4 hours, get your
neighborhood database boy to write a stored procedure that deletes rows from
CData and CGlobal tables in the client DB if the date field (don't wanna
look it up now) is older than a certain value.
There is absolutely no difference (that cannot be easily overcome) between
using session and client variables other than storage location.
NAT
----- Original Message -----
From: "Donald R. Pavlik" <[EMAIL PROTECTED]>
To: "Fusebox" <[EMAIL PROTECTED]>
Sent: Saturday, December 02, 2000 11:26 PM
Subject: RE: (In)Securing a FuseBox Application
> I have not done too much testing in the cookies and client/session
variable
> sets, but I have read a few posts concerning the cookies set in he
browsers.
> And I know that when I log into some of my websites I am a member too I
> don't have to log into them, even when I have not clicked remember me
option
> for when I log in. I was wondering if you have used any JavaScript to
make
> sure that if you wish to increase this level of security with each client
> that, lets say for example we have 3 clients all using the same machine
and
> all are members to the same site, now when we have anyone of these clients
> we wouldn't want either user to be able to access the previous account
info,
> so we could add a few event handlers to make sure if you use a cookie,
that
> the events of the location changing from your application or browser
> closing, or if log out is clicked that the cookie is destroyed by
JavaScript
> by setting the cookies time to 0, or I know there is a word for this, but
I
> am tired so you will have to bear with me:) and you could do a similar
thing
> with server side by having a the JavaScript send a url to the server upon
> one of these actions being performed too. That seems to me, in this tired
> state of mind, to be a work around that is able to handle a security
> problem, which I see arising, but never addressed. Or I could just be
> stating something you all already know:) oh well, just thought I ask/add
my
> two cents:)lol
>
> Donald R. Pavlik
> Founder
> Bug Engineering Co.
> "Making the Dreams of Tomorrow, Reality Today"
>
> -----Original Message-----
> From: Dave McKenna [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, December 02, 2000 2:37 PM
> To: Fusebox
> Subject: (In)Securing a FuseBox Application
>
>
> Okay, so I've read Chapter 7 of The (most excellent) Book. I think
there's
> something I've missed, though; it appears to me that the security model
is
> fundamentally based on the use of client variables, which persist across
> client sessions - wherein lies my problem. The FIRST login seems fine,
when
> a new user registers & logs in, and CLIENT.USER_ID is set by
app_Login.cfm.
> The pages that I want to secure should reference app_Secure.cfm, which
then
> looks for CLIENT.USER_ID; if it's defined, no login is required. That's
> where my eyebrows raised. I've got the default setting in the
Administrator
> for client variable purging, which is 10 days. So, if my user returns any
> time in the ensuing 10 days after they are first determined to be a
> "registered user", they don't need to log in. HOWEVER... client variables
> are tied to the browser, not the user. I know essentially nothing about
the
> environment from which my users may be accessing my site; sure, they might
> be at home or on their "own" PC at work, but they may also be a university
> student using a shared PC in a Computer Lab, etc... Meaning, of course,
that
> multiple users viewing my site from the same computer appear to be the
same
> user to the security system.
> So, what have I missed? There's a couple of workarounds I can think of
off
> the top of my head, but I'm interested to know what the intent of the
model
> proposed in the book is.
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
