Strange - my DB background is what makes me think of things like arrays of structs - like
tblCustInfo.firstName tblCustInfo.lastName ... -----Original Message----- From: Drew Harris [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 04, 2002 4:12 PM To: Fusebox List Subject: Re: forcing user to login I see. I suppose that my DB background keeps me thinking in simple types of data so I can easily get that information in and out of my database(s). Thanks, -Drew Harris On 6/4/02 3:03 PM, "Roger Dahlstrom" <[EMAIL PROTECTED]> wrote: > You could make the same basic argument for just about anything I suppose. > There's very little that you can do with a complex data type that you can't > do with standard variable names. I just prefer to use a struct becuase it > somehow makes more sense in my mind. > > -----Original Message----- > From: Drew Harris [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 04, 2002 3:01 PM > To: Fusebox List > Subject: Re: forcing user to login > > > What is the advantage of putting complex data in a client variable anyway? > Why would you not just have multiple client variables like: > client.authenicated, client.userid, client.password, client.firstname, > client.lastname...? > > -Drew Harris > > On 6/4/02 1:56 PM, "Jeff Peters" <[EMAIL PROTECTED]> wrote: > >> Well, you're not required to use WDDX, but the client scope will only > accept >> simple data types, so you must convert >> the structure to a simple data type. Using WDDX is an easy way to do > that. >> >> - Jeff >> >> On 4 Jun 2002 at 14:30, Troy Murray wrote: >> >>> >>> So let me make sure I have this straight. If I use CLIENT VARIABLES, I > cannot >>> use the structure >>> that I'm currently keeping in a SESSION VARIABLE without performing some > type >>> of WDDX >>> conversion back and forth? >>> >>> -T >>> >>> >>> -----Original Message----- >>> From: Richard Lamb [mailto:[EMAIL PROTECTED]] >>> Sent: Monday, June 03, 2002 10: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(tm)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(tm)ve >>> tried the >>> fbx_Setting in the root circuit, but it(tm)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 ==^================================================================
