Cold Fusion Session Swapping


I'm runnning into an interesting problem with CF session variables getting swapped by (I think) the server. If two users come in from the same IP (behind a firewall or NAT or whatever) within a minute of each other, they occasionally get the other person's session ID. Macromedia has a page on their site that gives a solution to this problem -- their solution being check and make sure the IP's are different.

Obviously, this doesn't work in this case, since we know the IP's are supposed to be the same.

Has anyone had any similar problems and found a way around them? Or can you point me to a site with more information on this topic than the Macromedia site? Thanks! :-)

Jaxman
jaxmanAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
YogConnect With a Mentor Commented:
Jax,

yeah locking may require if you are not making a copy of it and using even for a Request scope. If you turn on (from CF Administrator) stricter checking it will tell you wheather the code is not behaving well or behaving well.

if you are using the Request scope, make sure you use the duplicate if you are making another copy of it and using, an "=" usage may just make a reference and wont help

eg.

<CFLOCK SCOPE="Application" TIMEOUT="10">
<CFSCRIPT>
  Request.Application = StructNew();
  Request.Application = Duplicate(Application);
</CFSCRIPT>
</CFLOCK>

<CFLOCK SCOPE="Session" TIMEOUT="10">
<CFSCRIPT>
  Request.Session = StructNew();
  Request.Session = Duplicate(Session);
</CFSCRIPT>
</CFLOCK>

This was suggested to me by pikala and it works good.

Yog
0
 
YogCommented:
are you using CFLOCK when setting and reading session variables, http://www.sys-con.com/coldfusion/article.cfm?id=135
0
 
jaxmanAuthor Commented:
I'm going through and doing a thorough check on all the code, but I believe everything is locked down appropriately.

We've got a situation where we're using session.datasource to hold our DSN, and then at the top of application.cfm we're assigning it to request.appDSN so we can work with it in the request scope ever after instead of the session scope (to make locking easier to deal with).

Question: Will reading from a session variable (ie: putting session.datasource as an r-value of an operation) potentially cause corruption if not properly locked, or is it only when the session variables are l-values?


Jax
0
 
jaxmanAuthor Commented:
I'll have to give that a try...you've given me some good pointers, its going to take a while to test them out (these non-deterministic problems are crazy to track down). Thanks for the info! :-)

Jax
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.