Yeah, I know. But sometimes the problem is that if you have different types, then you either have to check everything or serialize/deserialize everything. Wasted about 2 hours trying to find a lazy man's solution to a problem that could have been solved in about 30 seconds of coding.
-----Original Message----- From: Alan McCollough [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 04, 2002 3:47 PM To: '[EMAIL PROTECTED]' Subject: RE: forcing user to login writing to/from WDDX is the solution. It's easy to do, in fact, I think there are both custom tags and UDFs folks have put together to make it easy. > -----Original Message----- > From: Roger Dahlstrom [SMTP:[EMAIL PROTECTED]] > Sent: Tuesday, June 04, 2002 10:41 AM > To: '[EMAIL PROTECTED]' > Subject: RE: forcing user to login > > If you come up with a way of easily writing a complex structure to a > database type varchar or text without using WDDX, please share. I've run > into the same thing, and found that I could only get it to work if I did > convert it to/from wddx. > > -----Original Message----- > From: Troy Murray [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, June 04, 2002 2:31 PM > To: [EMAIL PROTECTED] > Subject: RE: forcing user to login > > > 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'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 ==^================================================================
