I've never had a session write or a session read fail on me, because
thank God, right after I learned what a session was, someone sent me
to research CFLOCK.

But I've seen them fail on other cf sites... a session read actually..
no data was being written at the time... I was browsing a forum one
day and I don't know what happened but I posted a response to someone
and I was posting as a different user... A user who I'd never met so I
had no access to his account.

I don't know what happened.. it probably wasn't strictly a read...
something invisible in the site.. like a lastAccessed variable was
probably being set, and whadya know, I come out as a different user. I
had to email the guy and tell him to change his password because if it
happened to me, it could happen to others and while I didn't look up
his password, someone else could have.

That is (or at least was) the apparent flaw to cf's sessions.. its not
one field that gets switched... it was the whole session.

On Fri, 31 Dec 2004 17:53:15 -0500, Jim Davis
<[EMAIL PROTECTED]> wrote:
> > -----Original Message-----
> > From: Tony Hicks [mailto:[EMAIL PROTECTED]
> > Sent: Friday, December 31, 2004 5:35 PM
> > To: CF-Talk
> > Subject: Re: Well - I feel like an idiot.
> >
> > Many session-based sites run well without any cflocks but they're
> > smaller sites.. It doesn't seem to me to be a policy of knowing what
> > your doing or not, its more about the fact that you don't ever want
> > data mixed up, ever.
> >
> > To me its worth a few more lines of code to always protect my user's
> > data. I can see where locking or not locking application variables
> > could be harmless but I stand firm on sessions needing to be locked.
> 
> As I've been saying (in my opinion) if you're unsure, lock.
> 
> However if you are sure that not locking will not cause any issues, then its
> only better performance to drop needless code.
> 
> Most people would agree that many (if not all) session reads (for example)
> don't need to be locked (depending on the application of course).
> 
> For example consider the common practice of placing a "LastAccessed"
> timestamp in your session scope.  This variable is updated with the current
> when a user makes a request.
> 
> If two templates attempt to update the value at the same time it doesn't
> matter (at least to my application): the time is only used to determine if a
> session is "stale" so either time is fine as they're both essentially the
> same.
> 
> Personally I wouldn't lock that write in CFMX (in previous versions I
> would).
> 
> To me it's always about the current situation.  I agree in general that
> session data generally needs to be locked, but each situation presents
> different circumstances.
> 
> Jim Davis
> 
> 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Special thanks to the CF Community Suite Silver Sponsor - New Atlanta
http://www.newatlanta.com

Message: http://www.houseoffusion.com/lists.cfm/link=i:4:189091
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54

Reply via email to