20 cookies per domain if I remember correctly.
----- Original Message -----
From: "Steve Bryant" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, June 04, 2002 5:32 PM
Subject: RE: forcing user to login
> I am more of a DB person as well. However, the argument can be made
against
> writing things to a database before a transaction is complete (more trips
> to the DB and all of that). Additionally, there is a limit to the number
of
> cookies a browser will hold from a given domain name (I can't remember
what
> that limit is off the top of my head though).
>
> Using WDDX, you have to worry about string size limitation, but you can
> store more variables in fewer cookies.
>
> At 08:07 PM 6/4/2002 +0000, you wrote:
> >Thanks for clearing that up.
> >See, that's why I am more of a DB guy than a programmer.
> >Personally I'd rather do it all with queries, then it's avliable in my
> >DB for other apps, systems and what not to get at.
> >However, I can see possible advantages of this sort of thing.
> >
> >Thanks again,
> >Drew Harris
> >
> >Alan McCollough wrote:
> > > The benefit of using structures (vs. arrays, or individual vars)
exists
> > > independently of what scope the var is in.
> > >
> > > Well, lets say you've got a user, and for each user you want an ID, a
> > > username, and a fullname
> > > You could go...
> > > client.id
> > > client.username
> > > client.fullname
> > > or you could do a structure "user"
> > > and have
> > > user.id
> > > user.username
> > > user.fullname
> > >
> > > So what?
> > >
> > > Want to see all the dope on your user?
> > > <CFDUMP var="user">
> > >
> > > Want to have a load of 15 users?
> > > <CFSET user = ArrayNew(1)>
> > > <CFLOOP from="1" to ="15" index="loopindex">
> > > <CFSET user[loopindex].id = {something}>
> > > <CFSET user[loopindex].username = {something}>
> > > <CFSET user[loopindex].fullname = {something}>
> > > </CFLOOP>
> > >
> > > Then you can zip the whole wad up
> > > <cfwddx action="CFML2WDDX" input="#user#" output="wddx_temp">
> > > <cfset client.user = wddx_temp>
> > >
> > > And you want to git it back out?
> > >
> > > <CFSET user = ArrayNew(1)>
> > > <cfwddx action="WDDX2CFML" input="#client.user" output="#user#">
> > >
> > > it's all good...
> > >
> > > > -----Original Message-----
> > > > From: [EMAIL PROTECTED] [SMTP:[EMAIL PROTECTED]]
> > > > Sent: Tuesday, June 04, 2002 11:32 AM
> > > > To: [EMAIL PROTECTED]
> > > > 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
> > > >
> > > >
> > > > Jeff Peters 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
==^================================================================
