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 ==^================================================================
