Actually, the client scope only reads at the beginning of the request and
writes at the end of the request.
Nate
Alan McCollough
<amccollough@anmc To: "'[EMAIL PROTECTED]'"
<[EMAIL PROTECTED]>
.org> cc:
Subject: RE: forcing user to login
06/04/2002 12:12
PM
Please respond to
fusebox
Naw, if you are dealing with performance, all you gotta do is when you call
a fuseaction (start through the big switch), get all the client vars up
front and move 'em to a different scope like the request, attributes, or
variables scope. When you are at the end of a fuseaction, and ready to do a
CFLOCATE or something, write the variables back out to the client scope. If
you've got arrays/structures, you'll need to WDDX 'em first, but that ain't
a big hassle.
> -----Original Message-----
> From: Richard Lamb [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, June 03, 2002 6:38 PM
> To: [EMAIL PROTECTED]
> Subject: RE: forcing user to login
>
> My 2 cents. I think using client variables for the security aspect is
> great. But I also know that usually the bottleneck in an application are
> those darn database calls. Considering this, I think it would handicap
you
> greatly to limit your thinking one way or the other exculsively. I think
> even in a clustered enviroments, you would benifit moving client
variables
> that have extensive calls to session variables for the pupose of reading
> within the app.
>
> Rick
>
> -----Original Message-----
> From: Jeff Chastain
[mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 03, 2002 8:10 PM
> To: [EMAIL PROTECTED]
> Subject: RE: forcing user to login
>
>
> For the original question ... I tend to build a fuseaction
> (checkLogin) that I can use cfmodule to call and check the users
> credentials. That way the actual check code is encapsulated in the login
> circuit (i.e. my current circuit only needs to know the user is logged
in,
> not how to check for it). With the cfmodule call, I can also put it in
> individual fuseactions rather than trying to secure a whole circuit. So
> far it seems to work well and nobody has offered a reason yet not to do
so
> (I can already here them coming ;-))
>
> On the second point, I as well have always stuck to client
> variables. The primary reason is just being lazy - I did not want to
> have to mess with locking session or app. variables. I have not had to
> deal with a clustered environment, but that would be a definite reason to
> avoid them. I have been debating trying session variables again now
that
> MX does not require locking, but my client variables work fine - why
would
> I need session variables?
>
> -- Jeff
>
> -----Original Message-----
> From: Timothy Heald [mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 03, 2002 8:25 PM
> To: [EMAIL PROTECTED]
> Subject: RE: forcing user to login
>
>
> I know the question wasn't directed at me, but as
I only use
> client vars, I think I can add an answer.
>
> Ease of use.
>
> No locking. Ever. I don't feel the need to use
application
> or server scoped variables either. What little I may loose by not using
> them, I make up for in performance. No variables maintained in memory,
no
> fear of those variables getting corrupted. It's client variables, stored
> in a DB for me all the way.
>
> Tim.
>
> -----Original Message-----
> From: Troy Murray
[mailto:[EMAIL PROTECTED]]
> Sent: Monday, June 03, 2002 8:39 PM
> To: [EMAIL PROTECTED]
> Subject: RE: forcing user to login
>
>
> Drew,
>
> I'm curious, other then having
clustered
> environments, was there anything else that lead you to use CLIENT vs.
> SESSION variables?
>
> -T
>
> -----Original Message-----
> From: Drew Harris
[mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 31, 2002 5:49 PM
> To: Fusebox List
> Subject: Re: forcing user to login
>
>
> I used session then at the last
Fusebox conference
> got hammered about questions regarding it in the session I gave about
> using Fusebox for Enterprise applications when I was talking about this
> security app that I had built.
> Now I use a client variable, session
variables are
> dangerous in clustered environments.
>
> And to answer your question, I put
mine at the top
> of the fbx_switch page just before my cfswitch begins.
>
> -Drew Harris
>
> On 5/31/02 4:17 PM, "Tom Schreck"
> <[EMAIL PROTECTED]> wrote:
>
>
>
> Where's the best place to put the
logic to check for
> the presence of a session variable to determine if the user should be
> forced to login? The session variable indicated the user has logged in.
> The absence of one indicates the user needs to login. I've tried the
> fbx_Setting in the root circuit, but it's not working.
>
>
>
> Thanks -
>
>
>
> Tom Schreck
>
> 817-252-4900
>
> [EMAIL PROTECTED]
>
>
>
> I have not failed. I've found 10,000
ways that
> won't work.
>
>
>
> - Thomas Edison
>
>
>
>
>
>
>
>
>
>
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
