Thanks for the answer :) Maybe running the site and the blogs on separate instances is the main problem here. I don't have any session replication set up. That said, I did have the blogs recognizing the session from the main site. As in, it would pick up on the username, userid, etc.. that were all set prior to hitting up the blog. So was able to carry across. It's just when some members try to log in to these private blogs, it lost it. Seems quite crazy to me. For now, I've reverted the code back to what it was before - which basically does no manual setting of cookies and enables clientManagement again. The login to private blogs works as a result, but the carrying across of sessions from the main site doesn't.
My only question with your approach is how do you ensure the jsessionid cookie is set as a domain cookie? By default it always includes the subdomain and I can't find any way of overriding that. If setDomainCookies would work on jsessionIDs, then I guess the problem would be solved, but it doesn't :( And yeah, you're right, I probably should switch these blogs to application.cfc. We're using that on the main site now, but haven't done so for the blogs yet. Now's probably as good a time as any. On Dec 6, 5:51 pm, MrBuzzy <mrbu...@gmail.com> wrote: > Hi Peter, I use j2ee sessions and use cookies across sub domains with no > issue :) > > Without delving too deeply, I'd suggest removing your 'custom' session cookie > handling and clear your cookies from your browser before continuing. > > Keep this in mind, you will only have one jsessionid, but you may still have > multiple coldfusion sessions aka scopes, this is defined by the cfapplication > tag. Do your blogs each have their own application name, and therefor session > scopes? That may be why people appear to be logged out, because you are > bouncing between different session scopes. If you want to store the login > state across multiple subdomains they must all share the same application > name. > > Btw, I'd strongly advise using an Application.cfc instead. It just makes the > whole thing easier to manage (and debug perhaps). > > Looking at the code you've provided I'm guessing you are not using cflogin, > but rolling your own login mechanism, by storing the login state in session. > Nothing wrong with that :) > > A couple of other tips; > Use the onsessionstart method to log when a session really starts. > If you're invalidating the jsessionid cookie a new session will be created > for each application. Probably not what you want :) > If you are passing the jsessionid across multiple coldfusion instances, you > will need to setup session replication. > > Sorry I have to run but I'll keep an eye out if you have follow up questions. > > Cheers. > > Sent from my iPhone > > On 06/12/2010, at 5:04 PM, daamsie <pe...@travellerspoint.com> wrote: > > > > > > > > > Having some major battles trying to get sessions to work neatly across > > subdomains at the moment. We're using J2EE session management. I > > implemented the advice in this blog post to ensure that a domain > > cookie was set, rather than the default which is a cookie specific to > > the > > subdomain;http://www.coldfusionmuse.com/index.cfm/2006/7/28/sessions.and.subdom... > > > Then I noticed that a jsessionID cookie was still being set for the > > subdomain and it was different to my domain cookie which had been set > > on our main site, not the blog. So my next idea was to override the > > subdomain cookie. Here's the code I ended up with: > > > ========= > > <cfapplication name="foo" sessionmanagement="yes" > > sessiontimeout="#CreateTimeSpan(0,1,30,0)#" > > applicationtimeout="#CreateTimeSpan(0,1,30,0)#" setclientcookies="no" / > > > <!--- handling session cookies ourselves ---> > > <cflock scope="Session" type="exclusive" timeout="30"> > > <cfif isDefined('cookie.jsessionID')> > > <cfset session.sessionID=cookie.jsessionID /> > > <cfelse> > > <cfcookie name="jsessionid" domain=".foo.com" > > value="#session.sessionid#"> > > </cfif> > > <cfcookie name="jsessionid" value="#session.sessionid#"><!--- set > > explicitly for the subdomain since there doesn't be any way to stop cf > > from setting this itself ---> > > </cflock> > > ========= > > > So now, I managed to get two cookies set with identical sessionIDs. > > Woopee! Well, not quite. > > > Some of our blogs are private, so whoever visits it will need to enter > > a password to get in. And the whole thing fails miserably there. > > People try to log in, it logs them in successfully and then redirects > > them to the blog and then they're not logged in any more. > > > To analyze the problem I cfmailed myself the session scope before > > attempting to login, after the successful login and again after the > > redirect. Here's what it looks like (simplified for clarity's sake) > > > ====== > > Before Login: > > ----------------- > > session.userid 1 > > session.sessionid ffffff > > session.urltoken CFID=1&CFTOKEN=5&jsessionid=44444 > > > ====== > > After Successful Login (the login is successful here, because the > > session.secure_blogIDs variable now exists) > > ------------------ > > session.userid 1 > > session.secure_blogIDs 1 > > session.sessionid ffffff > > session.urltoken CFID=1&CFTOKEN=5&jsessionid=44455 > > > ====== > > After Redirect (note, secure_blogIDs variable disappears) > > ------------------ > > session.userid 1 > > session.sessionid ffffff > > session.urltoken CFID=1&CFTOKEN=5&jsessionid=44466 > > > As you can see, the session.urltoken keeps changing, though the > > session.sessionID manages to stay the same. I've tried manually > > setting the session.urltoken to ensure it is consistent as well. > > Managed to do that, but the same problem still happens. > > > Does anyone have a better understanding of how these j2ee sessions > > work? I'm just not having much luck with them and not finding any > > useful information on the interwebs about it either. > > > Cheers, > > Peter > > > -- > > You received this message because you are subscribed to the Google Groups > > "cfaussie" group. > > To post to this group, send email to cfaus...@googlegroups.com. > > To unsubscribe from this group, send email to > > cfaussie+unsubscr...@googlegroups.com. > > For more options, visit this group > > athttp://groups.google.com/group/cfaussie?hl=en. -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
