You said, "
> Yep, thanks, I'm on track with that part; it's the *after* a
> session part
> that bothers me... when my user gets up and walks away from
> the keyboard,
> and someone ELSE sits there. If the user logs out or closes
> their browser,
> their state goes away when I'm using session variables; that's not
> necessarily the case with client variables."
Not true. If a user closes a browser, gets up from a public-type terminal
and a new user sits down, the new user can access the previous user's
session regardless of client or session vars used. Why do you think there
is?
If, any time until the session/client data is purged from the CF system
(using purge client vars or session timeout values) another browser anywhere
in the world uses the same CFID/CFToken combo on a URL, they get that
session. I think you know this, but I just wanna be clear.
There is no difference in the security levels of client variables vs.
session variables. The only percieved difference is the timeout values.
More?
NAT
> -----Original Message-----
> From: Dave McKenna [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, December 02, 2000 12:25 PM
> To: Fusebox
> Subject: RE: (In)Securing a FuseBox Application
>
>
> > Although I'm a little unclear of your exact intentions and question
>
> Jeez, how lucid do I have to BE on a Saturday? :-)
>
> > Did I answer your question?
>
> Pretty much, thanks - when you said "...use session variables...". I
> mentioned "a couple of workarounds" in my original post; one
> would be to
> rewrite the app_secure so that it uses only session
> variables; the other
> (quicker) is just to have a single "Session.LoggedIn"
> variable set after a
> successful login, and add a test for that in the app_Secure.
> The problem
> here, though, would be the ensuing loss of state in a
> failover scenario.
> Damned if you do, damned if you don't?
>
> > I
> > assume it has to do with the length of time the client
> > variables persist.
>
> Exactly. Truthfully, I conceptualize client variables as
> being the way I
> maintain state across a cluster. Although we can also use
> them to maintain
> state across distinct browser sessions, I'd rather not do
> that since I've
> always been hung up on the fact that client variables are
> tied only to the
> browser, not to a specific user (although it's *possible* to
> programmatically forge the link, it's a bit of a pain to do
> so. I don't
> think I've seen a truly adequate way of doing so yet). So,
> any security
> system intended to identify a distinct user through the use of client
> variables raises a BIG red flag for me.
>
> > In case you didn't know this (but it sounds like you do by
> > the tone of your
> > post) ...everytime the client hits their variables,
> > the count starts over again...
>
> Yep, thanks, I'm on track with that part; it's the *after* a
> session part
> that bothers me... when my user gets up and walks away from
> the keyboard,
> and someone ELSE sits there. If the user logs out or closes
> their browser,
> their state goes away when I'm using session variables; that's not
> necessarily the case with client variables.
>
> I do think it's worth mentioning, though, that The Book's
> security model has
> this limitation.
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
