I think I've heard someone describe Ken's example as the "Throwing a brick over the wall method" if I'm not mistaken. It seems like a good way to do it.
If app 1 an app 2 tursted each and were both managed by the same person would it be possible to just write to the database on app2 after finishing writing to app 1? I guess it would depend on how tightly integrated they are. Having a single sign-on for multiple apps seems quite feasable if they are on the same server. I've never had to do it so I'm not sure about the complexity of writing to a second database but it is possible via Linked server on MS SQL Server. -Eddie Pequeno --- On Thu, 12/17/09, Ken Auenson, II <[email protected]> wrote: > From: Ken Auenson, II <[email protected]> > Subject: Re: [houcfug] question about client vars > To: [email protected] > Date: Thursday, December 17, 2009, 3:53 PM > Mark, > I tend to use an ugly mix of cookies and database > records in these situations. > I use a cookie to identify the user and that they are > authenticated, then I store the specific user data in the > database. > > Then when a user enters the secondary application for > the first time, I look for the cookie, load the data from > the DB and set a session variable to indicate that they have > been loaded. > --Ken > > > > > > On Thu, Dec 17, 2009 at 3:49 PM, > Mark Davis <[email protected]> > wrote: > > > > > > > > Thanks Charlie. Not sure why I thought > client > vars persist across apps. Is there any other way to > persist variables > across applications and still be specific to each client? > Guess > not. > > > > > From: [email protected] > > [mailto:[email protected]] > On Behalf Of Billy > Cravens > Sent: Thursday, December 17, 2009 2:56 PM > To: > [email protected] > Subject: Re: [houcfug] question about client > vars > > > I guess this is one of those rare situations > where you could use > server scope. (Since 4.0, I can't remember when I ever > have.) Rather than > persist in server scope, copy client vars in and out using > duplicate()???? It'd > be easy in BD, where they have onClientStart - was this > added to CF9?? > > Billy Cravens > > > > On Thu, Dec 17, 2009 at 2:36 PM, > charlie arehart <[email protected]> > > wrote: > > > > > Hey > Mark, client variables are indeed tied to applications. > If one uses a database > for the client variable storage, you can see in the cdata > table that app is a > key. > > So only if those two cfapplication tags had the same name > (or no > name) would they be shared this way. > > > /charlie > > > > From: [email protected] > [mailto:[email protected]] > On Behalf Of Mark > Davis > Sent: Thursday, December 17, 2009 2:34 PM > To: [email protected] > Subject: [houcfug] > question about client vars > > > Let me > set the stage...two > distinct apps (meaning separate cfapplication tags). In > app 1, user gets > authenticated, set some client variables with specific > user info, the > cflocate them to app 2 and all client vars the just set > client vars are > gone. Haven;'t worked with client vars in may > moons, but they are > supposed to be available across applications, > right? > > > > App1: > > > > <cfapplication name="app1" > sessionmanagement="true" > loginStorage="session" > clientstorage="dsnName" > clientmanagement="true"/> > <cfset > client.xxx = > "1"/> > <cfset > client.yyy="2"/> > <CFLOCATION URL="/app2/index.cfm" addtoken="false"/> > > > > App > 2: > <cfapplication name="app2" > > > sessionmanagement="true" > > > loginStorage="session" > clientstorage="dsnName" > > > clientmanagement="true"/> > > > "Element xxx > undefined in > client" > > -- > You received this message because you are subscribed > to the "Houston ColdFusion Users' Group" > discussion list. > To unsubscribe, > send email to [email protected] > For more options, > visit http://groups.google.com/group/houcfug?hl=en > -- > You received this message because you > are > subscribed to the "Houston ColdFusion Users' > Group" discussion list. > To > unsubscribe, send email to [email protected] > For more options, > visit http://groups.google.com/group/houcfug?hl=en > > -- > You received this message because you are subscribed to the > > "Houston ColdFusion Users' Group" discussion > list. > To unsubscribe, send email > to [email protected] > For more options, visit http://groups.google.com/group/houcfug?hl=en > > > > > > -- > > You received this message because you are subscribed to the > "Houston ColdFusion Users' Group" discussion > list. > > To unsubscribe, send email to [email protected] > > For more options, visit http://groups.google.com/group/houcfug?hl=en > > > > > -- > > You received this message because you are subscribed to the > "Houston ColdFusion Users' Group" discussion > list. > > To unsubscribe, send email to > [email protected] > > For more options, visit http://groups.google.com/group/houcfug?hl=en -- You received this message because you are subscribed to the "Houston ColdFusion Users' Group" discussion list. To unsubscribe, send email to [email protected] For more options, visit http://groups.google.com/group/houcfug?hl=en
