|
Mailing Lists
|
Home /
Groups /
ColdFusion Talk (CF-Talk)
User Authentication
These are probably dumb questions and think I know the answers, but I need affirmation from my peers.Greg Landers 06/03/04 11:36 P My two cents...Arden Weiss 06/04/04 03:24 A Session variables use persistent cookies also unless you code the CFIDMarlon Moyer 06/03/04 11:44 P So session variables work differently in MX then? What about people withPaul Wilson 06/04/04 03:24 A For people with no cookies, you need to pass the apropriate info on thePascal Peters 06/04/04 04:10 A >>Session variables use persistent cookies also unless you code theKenneth Wilson 06/04/04 08:19 A See --> http://www.macromedia.com/support/coldfusion/ts/documents/tn17915.htm for full explanation.Semrau Steven Ctr SAF/IE 06/04/04 10:37 A Originally the poster was comparing native session vs native clientMarlon Moyer 06/04/04 10:41 A > See -->Dave Watts 06/04/04 12:19 P You should share that info with MM and have them update the TechNote for future reference.Semrau Steven Ctr SAF/IE 06/04/04 12:40 P > Maybe I am off-base, but I only use session variables forDave Watts 06/05/04 10:53 A These are probably dumb questions and think I know the answers, but I need affirmation from my peers. Which is considered a better practice: storing user variables like customerID and customerIsAuthorized in a locked session scope; or, simply set cookies on the user's machine? Will using the session scope greatly reduce the portability of the application? In other words, is it common to find hosts or individuals running CF server with the session variables disabled in the CF administrator? Likewise, I know that a small percentage of the people using the Internet have their privacy settings set very tight - making cookies not the best practice to use when it comes to application functionality. Setting cookies makes for more portable code - at the risk of sacraficing functionality, and using session variables risks losing portablility while ensuring that the application functions for every user. Any thoughts and/or advice will be greatly appreciated. - Greg My two cents... Maybe I am off-base, but I only use session variables for login management purposes -- instead I mostly use client variables to gain inter-template communication -- the advantage of this is that no locking is required. Guess there are some disadvantages, but I haven't found them yet and would like to be enlightened, etc. Session variables use persistent cookies also unless you code the CFID and CFToken into the URL, or you use j2ee session management. -- Marlon Moyer, Sr. Internet Developer American Contractors Insurance Group phone: 972.687.9445 fax: 972.687.0607 mailto:mmoyer@acig.com www.acig.com > These are probably dumb questions and think I know the answers, but I need > affirmation from my peers. > > Which is considered a better practice: storing user variables like > customerID and customerIsAuthorized in a locked session scope; or, simply ----- Excess quoted text cut - see Original Post for more ----- Internet > have their privacy settings set very tight - making cookies not the best > practice to use when it comes to application functionality. > > Setting cookies makes for more portable code - at the risk of sacraficing > functionality, and using session variables risks losing portablility while ----- Excess quoted text cut - see Original Post for more ----- So session variables work differently in MX then? What about people with cookies turned off in their browsers? Session variables use persistent cookies also unless you code the CFID and CFToken into the URL, or you use j2ee session management. -- Marlon Moyer, Sr. Internet Developer American Contractors Insurance Group phone: 972.687.9445 fax: 972.687.0607 mailto:mmoyer@acig.com www.acig.com > These are probably dumb questions and think I know the answers, but I need > affirmation from my peers. > > Which is considered a better practice: storing user variables like > customerID and customerIsAuthorized in a locked session scope; or, simply ----- Excess quoted text cut - see Original Post for more ----- Internet > have their privacy settings set very tight - making cookies not the best > practice to use when it comes to application functionality. > > Setting cookies makes for more portable code - at the risk of sacraficing > functionality, and using session variables risks losing portablility while ----- Excess quoted text cut - see Original Post for more ----- _____ For people with no cookies, you need to pass the apropriate info on the url (this was always like this). In MX you can use J2EE sessions and the function URLSessionFormat to do that: <a href="#URLSessionFormat('index.cfm?fuseaction=site.form&id=' & variables.id)#"> <form method="Post" action="#URLSessionFormat('index.cfm?fuseaction=site.action')#"> <cflocation url="#URLSessionFormat('index.cfm?fuseaction=site.home')#"> <form method="Get" action="#URLSessionFormat('search.cfm')#"> If you are not using J2EE session, this won't work for the form with method="get". You will need to add two hidden form fields for that form: <form method="Get" action="search.cfm"> <input type="Hidden" value="#session.cfid#" name="cfid"> <input type="Hidden" value="#session.cftoken#" name="cftoken"> Or if you only want the info added when necessary (if cookies are turned off or the server can't determine cookie support): <form method="Get" action="search.cfm"> <cfif "search.cfm" NEQ URLSessionFormat("search.cfm")> <input type="Hidden" value="#session.cfid#" name="cfid"> <input type="Hidden" value="#session.cftoken#" name="cftoken"> </cfif> HTH, Pascal > So session variables work differently in MX then? What about > people with cookies turned off in their browsers? >>Session variables use persistent cookies also unless you code the >>CFID and CFToken into the URL, or you use j2ee session management. This seems to be one of those common misperceptions that keeps getting repeated. While CF's native cookie setting may use persistent cookies, there's nothing at all stopping you from using session cookies with or without J2EE session management and pre or post CFMX. Just manually set the cookies rather than relying on the automatic setting of them. Ken See --> http://www.macromedia.com/support/coldfusion/ts/documents/tn17915.htm for full explanation. <!--- Use the following code to set per-session cookies instead of persistent cookies (ColdFusion TechNote 17915) ---> <cfapplication name="theAppName" sessionmanagement="YES" setclientcookies="NO" clientmanagement="NO" sessiontimeout="#CreateTimeSpan(0,0,20,0)#"> <cflock timeout="5" throwontimeout="no" type="readonly" scope="session"> <cfcookie name="CFID" value="#SESSION.CFID#"> <cfcookie name="CFTOKEN" value="#SESSION.CFTOKEN#"> </cflock> These are probably dumb questions and think I know the answers, but I need affirmation from my peers. Which is considered a better practice: storing user variables like customerID and customerIsAuthorized in a locked session scope; or, simply set cookies on the user's machine? Will using the session scope greatly reduce the portability of the application? In other words, is it common to find hosts or individuals running CF server with the session variables disabled in the CF administrator? Likewise, I know that a small percentage of the people using the Internet have their privacy settings set very tight - making cookies not the best practice to use when it comes to application functionality. Setting cookies makes for more portable code - at the risk of sacraficing functionality, and using session variables risks losing portablility while ensuring that the application functions for every user. Any thoughts and/or advice will be greatly appreciated. - Greg _____ Originally the poster was comparing native session vs native client variables. In that context, they both use persistent cookies. So the problem he was asking about would be no different for either scope. You are correct that you can easily change that. Here's a tech note that describes that exact process. http://www.macromedia.com/support/coldfusion/ts/documents/tn17915.htm Marlon ----- Excess quoted text cut - see Original Post for more ----- set > the cookies rather than relying on the automatic setting of them. > > Ken ----- Excess quoted text cut - see Original Post for more ----- It's worth pointing out that this will set the cookies on each page request. Rather than doing this, you can just check for the cookies' existence, and if they don't exist, set them then: <cfapplication ... setclientcookies="no"> <cfif not IsDefined("Cookie.CFID")> <cflock scope="Session" type="readonly" ...> <cfcookie name="CFID" value="#Session.CFID#"> <cfcookie name="CFTOKEN" value="#Session.CFTOKEN#"> </cflock> </cfif> Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444 You should share that info with MM and have them update the TechNote for future reference. ----- Excess quoted text cut - see Original Post for more ----- It's worth pointing out that this will set the cookies on each page request. Rather than doing this, you can just check for the cookies' existence, and if they don't exist, set them then: <cfapplication ... setclientcookies="no"> <cfif not IsDefined("Cookie.CFID")> <cflock scope="Session" type="readonly" ...> <cfcookie name="CFID" value="#Session.CFID#"> <cfcookie name="CFTOKEN" value="#Session.CFTOKEN#"> </cflock> </cfif> Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444 _____ > Maybe I am off-base, but I only use session variables for > login management purposes -- instead I mostly use client > variables to gain inter-template communication -- the > advantage of this is that no locking is required. > > Guess there are some disadvantages, but I haven't found them > yet and would like to be enlightened, etc. The obvious disadvantage is that client variables are significantly slower to access if they're stored in a database, which is the only decent place to store them. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444 FWIW, my testing on CF5 using GetTickCount() has indicated about a 15ms difference between using session versus db-stored client variables. Obviously, that's specific to my setup and app and assumes GetTickCount() provides a reasonably accurate way of measuring it. What is considered the best method if you need to support a cluster, don't want to rely on sticky sessions and aren't using the J2EE install of CFMX? Ken ________________________________ Sent: Sat 6/5/2004 10:58 AM To: CF-Talk Subject: RE: User Authentication > Maybe I am off-base, but I only use session variables for > login management purposes -- instead I mostly use client > variables to gain inter-template communication -- the > advantage of this is that no locking is required. > > Guess there are some disadvantages, but I haven't found them > yet and would like to be enlightened, etc. The obvious disadvantage is that client variables are significantly slower to access if they're stored in a database, which is the only decent place to store them. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 202-797-5496 fax: 202-797-5444
|
September 06, 2010
|
Latest Fusion Authority Articles
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||