Win2 upgrade, session variables

P

peskypup

Perch
Re-posting this in the CF forum in hopes someone has encountered and fixed this already:


There appear to be some ColdFusion issues on the new and improved Win2. Namely, it appears that CFREGISTRY is no longer disabled, and for some reason, using the <CFAPPLICATION> tag recommended in the "sticky" post at the top of the ColdFusion forum is no longer stroring session variables. For some reason, it appears cookies are not getting set, which causing my session variables to die between pages.

Here is the <CFAPPLICATION> tag I was using, that has been working on the server, untouched, for more than 6 months:

<cfapplication name="myapp" clientmanagement="yes" sessionmanagement="yes" setclientcookies="yes" setdomaincookies="yes" sessiontimeout="#createTimeSpan(0,0,60,0)#" applicationtimeout="#createTimeSpan(0,8,0,0)#" Clientstorage="Cookie" loginstorage="session">

This no longer works in IE... my best guess is that it has something to do with cookies and how they're being set...

I've changed the <CFAPPLICATION> tag to this:

<cfapplication name="tourgolfclubs_dev" clientmanagement="yes" sessionmanagement="yes" sessiontimeout="#createTimeSpan(0,0,60,0)#" applicationtimeout="#createTimeSpan(0,8,0,0)#">

And now it works. The default session storage method in ColdFusion is the registry, and my guess is that this is currently is being allowed, enabling the <CFAPPLICATION> tag above to work.

Anyway, since I fully expect Jodohost to stumble across this at some point in the future, and disable CFREGISTRY again, thus breaking the <CFAPPLICATION> tag I'm using currently, I figured I'd mention it now rather than discover it at some future date when I'm nowhere near a computer and my client calls me up fuming because his site isn't working again...

If anyone can tell me why the first <CFAPPLICATION> tag above is failing to set cookies/session variables, despite being the one recommended by Jodohost, I'd appreciate it. And before anyone mentions it, no, I am not using a <CFLOCATION> tag on the page on which I set the session variable... so that's not it. This is code that hasn't been touched and has been working fine for at least 6 months before this week, so it's not a code issue... it has something to do with the changes to the server this week. I just want to know what, if anything, I need to do to fix things so that I don't get any angry client emails.
 
Thanks for the reply... I've replied to you as well.

On a totally different note, but regarding the server upgrade, it appears that user accounts are on a different drive than they were on the old server. So any CFFILE tags that have the destination directory path hardcoded are going to break.

Previously the directory structure was set up like this:

C:\hshome\accountname\domain.com\

Now user sites are on D:\, so it needs to be changed to:

D:\hshome\accountname\domain.com\

If anyone's using CFFILE, you might want to look into this.

It's not a big deal, but it would have been nice to know ahead of time rather than finding out when the client I did this site for started getting errors all over his site. Was there any communication with customers to let them know these upgrads would be taking place... besides on this forum, which I simply don't have the time to read on a daily basis? It would have been nice to know there was a potential of things like this happening so I could monitor the site and catch and fix stuff in a timely manner.
 
Hello,

It is true that the drives changed, we did not think about it until after the files were moved and we got some tickets on it. That was my mistake.

Other than that, and the psoft migration script not running the migration went very well as far as migrations are concerned. I have seen migrations that are disasters, this one has had a few bumps, but nothing that has been a showstopper.
 
peskypup said:
On a totally different note, but regarding the server upgrade, it appears that user accounts are on a different drive than they were on the old server. So any CFFILE tags that have the destination directory path hardcoded are going to break.
Click to expand...

This is a lesson to NEVER hard-code file paths.... especially not when CF has such nice tools to handle path discovery for you. Here's what I do:

<cfset ThisDirectory = #GetDirectoryFromPath(ExpandPath("./*.*"))#>

Try it out and see what it'll do for ya!

Hatton
 
You must log in or register to reply here.
Back
Top