Dale I've used a combination of the Application specific sessioncookies.domain and the manual cookie set in the onSessionStart and it appears to be working which is odd? Previously i had tried these settings independently thinking the combination was pointless but I've tried in 3 different browsers and the session token holds when crossing between sub-domains. I'm not complaining though!
Good point about the cookies getting confused as I had seen that earlier with a very old non-domain scoped jsession cookie remaining dormant on the browser and causing a double up with the new domain specific cookie declaration. Everything appears to now be running over J2EE sessions with secure cookies, full HTTPS, and browser based cookies only which satisfies our PCI obligations. Thanks for your help everyone! On Monday, 7 April 2014 11:57:49 UTC+10, Dale Fraser wrote: > > Ive seen a cookie get lost / confused where there are multiple entries for > the domain it gets confused. > > > > I’d clear cookies, then watch what happens with cookies in chrome dev > tools or similar to see where it goes pear shaped. > > > > Regards > > Dale Fraser > > > > *From:* cfau...@googlegroups.com <javascript:> [mailto: > cfau...@googlegroups.com <javascript:>] *On Behalf Of *Phil Rasmussen > *Sent:* Monday, 7 April 2014 10:27 AM > *To:* cfau...@googlegroups.com <javascript:> > *Subject:* Re: [cfaussie] CF10 Cross Domain sessions with HTTPS > > > > Hi Dale thanks for the suggestion I had actually tried that and > unfortunately to no avail. > > > > I've tried setting the constructors as: > > > > this.sessioncookie.domain = '.domain.com'; > > this.sessioncookie.httponly = true; > > > > I've also tried setting the cookie manually in the onSessionStart() as > follows: > > > > <cfcookie name="jsessionid" value="#session.sessionid#" secure="true" > domain=".domain.com" encodeValue="false"> > > > > Also to no avail which is frustrating as I can't see why this wouldn't > work. > > > > On Monday, 7 April 2014 09:36:02 UTC+10, Dale Fraser wrote: > > I asked already, but what is your domain setting in application.cfc? > > > > this['sessioncookie']['domain'] = '.#cgi.server_name#'; > > > > This sets cookies for the domain rather than sub domain. > > > > Regards > > Dale Fraser > > > > *From:* cfau...@googlegroups.com [mailto:cfau...@googlegroups.com] *On > Behalf Of *Phil Rasmussen > *Sent:* Monday, 7 April 2014 9:34 AM > *To:* cfau...@googlegroups.com > *Subject:* Re: [cfaussie] CF10 Cross Domain sessions with HTTPS > > > > Andrew I understand and completely agree with the crossing between HTTP / > HTTPS and sessions dropping, however we have since switched the entire > application over to HTTPS across all the subdomains and still have the same > problem. > > > > I am basically trying to find a solution (any solution at this stage > hopefully aside from passing session tokens in the URL) that will keep > session persistence when jumping between the subdomains of the application. > > > > ie. https://profile.domain.com over to https://book.domain.com and back > to https://profile.domain should not drop the session at any stage and > this is what has me stumped as CF is continually issuing new session tokens > when this happens. > > On Friday, 4 April 2014 22:04:10 UTC+10, Andrew Scott wrote: > > > > > Regards, > > Andrew Scott > > WebSite: http://www.andyscott.id.au/ > > Google+: http://plus.google.com/113032480415921517411 > > > > > > On Thu, Apr 3, 2014 at 9:26 AM, Phil Rasmussen <ara...@gmail.com> wrote: > > Hi Guys > > > > > > When crossing between the domains (which had worked for many years prior) > the session drops and CF issues a new set of session identifiers. In order > to try and bypass the SSL issue, i've switch the entire application over > the HTTPS so at no stage will the session or cookies be served over HTTP, > which works fine if the user doesn't cross domains, but the moment a > different subdomain is clicked (ie to make a booking) then the session > drops. > > > > > > > > This is expected behavior, at least that is what I believe. The problem is > going to lie in your certificate and ColdFusion, but essentially it sounds > like Adobe has closed a security hole. As the session should not persist > from non secure to secure and back again, they should be seen as two > different sessions. > > > > Imagine if someone hacked the non SSL site, they would then have all the > information needed to get anything out of the SSL connection. I will admit > to not having done too much with SSL, but from what I have done, I think > the behavior you are now caught with is a closed security risk Adobe fixed > in ColdFusion 10. > > > > But I am going from a serious lack of knowledge here. > > > > -- > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to cfaussie+u...@googlegroups.com. > To post to this group, send email to cfau...@googlegroups.com. > Visit this group at http://groups.google.com/group/cfaussie. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to cfaussie+u...@googlegroups.com <javascript:>. > To post to this group, send email to cfau...@googlegroups.com<javascript:> > . > Visit this group at http://groups.google.com/group/cfaussie. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To unsubscribe from this group and stop receiving emails from it, send an email to cfaussie+unsubscr...@googlegroups.com. To post to this group, send email to cfaussie@googlegroups.com. Visit this group at http://groups.google.com/group/cfaussie. For more options, visit https://groups.google.com/d/optout.
