we are currently upgrading a SLES 11 Server to CF10 64bit.
Last week we spend 2 days to eliminate a problem with the connector.
Apache refused to deliver CF-Pages. The log file said that mod_jk could not connect to the cfusion instance - Error 503...
We finally fixed this by copying a mod_jk binary from a working CF10 Server to this one.
Now Apache (2.2.23) serves all CF pages flawlessly.
What I just discovered was a problem, when a client doesn't accept cookies and J2EE-Sessions are turned on.
A URL with the sessionid appended (as for example cflocation creates it) results in a 404 error:
I remember such a problem from a CF6/7 install, but that was IIS on Windows.
I'm just stuck with this one.
Can somebody please help?
Joerg, want to help (or help others help you). You say you “are stuck”, but said after “copying a mod-jk binary…Now Apache (2.2.23) serves all CF pages flawlessly.” Can you clarify what you are seeking then? Just an explanation? Or is something still broken?
You did find the culprit: with j2ee sessions enabled, a cflocation (without addurltoken=”no”) will cause it to create a URL with the sessiontoken added. Or if a client does not send cookies, then the urlsessionformat function will do it.
Or are you wondering more why (if all that was the same before) it worked before your upgrade to 10? In that case, it may help to specify what changed (CF, OS, web server) in terms of product or version.
glad to hear from you!
Maybe I have to clarify my problem...
Seems like I should not describe two problem at once
The story about mod_jk was just to introduce my scenario.
We just upgraded a SLES Server from Apache + CF 9 Std. on Jrun to CF10 Std.
After slight problem with mod_jk this server is now running some sites under constant observation.
Everything seemed to run smooth now, but I got note from a coworker, that he could not login.
It turned out that he had cookies disabled, so CF preseves the session by adding URL-params.
As we have J2EE Sessions turned on for years, cflocation adds ;jsessionid= to the URL.
That was no problem since the CF10 upgrade.
Now we are getting 404 Erros from apache, as he thinks that the file is named "login.cfm;jessionid=xxxxxx"
I'm now stuck at the point, that I don't know what to add to the apache config, so that he identifies this request to be for "login.cfm"....
One more thing
As we are experiencing several problems with our SLES server, I did a little test.
I just set up a completely new Ubuntu server 12.04.1 64bit with apache 2.2.22 and CF10 (including Update 1 + 2).
Everything went much smoother than on SLES
I setup a virtual host and copied a cf-application to it.
The site runs as expected. But when I turn on J2EE-Sessions and then disable cookies in my Browser, I again receive the message:
The requested URL /login.cfm;jsessionid=D490A98FF79AC72C5062A55324089C63.cfusion was not found on this server.
I haven't made any change to any config files except the vhost definition.
What do I have to add to the apache config to have this error disappear?
Regarding 404 and jsessionid in earlier versions of ColdFusion, there was an option you could enable in the connector settings so that the webserver would stop trying to parse the semicolon-jessionid (;jsessionid=) from the url. That setting is no longer applicable, but for reference here's a blog on it:
I tried to reproduce the issue you describe with CF10, but could not. I have CF10 (unpatched as of now) on CentOS 6.3 linux with Apache 2.2.15 (default settings). When I enable j2ee sessions and test a sample app that uses session management, I noticed that jsession id is no longer added with a semicolon, but rather it is now delimited with an ampersand &. If I dump the session scope, I see that session.urlToken has for example a value like this:
Notice the & delimiter rather than a ; delimeter. So I'm curious as to why your configuration has a ; instead.
I tested enabling and disabling cookies, and all cases a) the delimeter remained &, and b) I never encountered a 404 (verified in the error_log/access_log).
I also tested manually replacing the & with a ; in the URL, and the page still resolved correctly.
The only unsual behavior that I noticed is that when cookies were disabled, my CFID and CFTOKEN remained the same every request but the J2EE jsession id changed every request. Not sure what to say about that. When I renabled cookies, I found that all 3 tokens remained constant.
Looking for where the semicolon might be coming from, I noticed that in ColdFusion 10 urlsessionformat() still outputs a ; delimiter, even though cflocation addtoken uses an ampersand & and so does session.urltoken.
When I formatted a link with urlsessionformat that the link was created with a semicolon and the link still worked. I did not get a 404.
Your application may be using urlsessionformat on links, so if you don't find the Apache configuration option to allow semicolon delimiters, you could try replacing usage of #urlsessionformat('somepage.cfm')# with 'somepage.cfm?#session.urltoken#' instead.
Steven, great stuff. As for your last point, that’s the session fixation protection (new in CF10, or added in the security hotfixes on CF 9/9.0.1 or included in 9.0.2). The change of the sessionid under the cover is now automatic. Just google coldfusion session fixation to find more on that.
More good stuff. Thanks. Seems like a bug in urlsessionformat (overlooked in the update that changed the ; to & in cflocation’s addtoken). Hope one of you will open a bug report.
In the meantime, rather than swap the function (since it includes logic you’d need to replicate), I’d propose instead wrapping it in a replace function that just changes the ;jsessionid to &jsessionid.
Hope that’s helpful.
Steven: I remember reading your article back in the CFMX days... big thanks for that
But the ;jsessionid version is a absolutely correct behavior (for the whole tomcat serlet j2ee thingies) and should not be transformed anyhow.
In my case, ;jsessionid is added by urlsessionformat in a form action. Additionally I have nearly every link and every form action in my applications written with urlsessionformat(), as I have learned that this should be best practice. That's why I would expect this to run on CF8/9/10 equally.
I'd rather disable J2EE Sessions than changing all applications with urlsessionformat! But in the past (with CF6 and 7) we had some security issues without j2ee-sessions, so I'd like to stick with them.
As the appended ;jsessionid is syntactically correct, I would just expect the installed mod_jk to handle this suffix - but it doesn't. That's why I don't think that this is a bug in cflocation...
I just installed Update 3 which did not change anything here - just for info...
I think that this should be reproducable, as I ran into this on three different machines now. One Ubuntu, two with SLES. All 64bit, all with apache(2.2.22/2.2.23), all CF 10 Standard (installed from the product DVD).
Default Configuration nearly untouched, just activated j2ee-sessions and added a datasource.
Disable cookies in Firefox 16.0.1 or Chrome 22 and post a form where the form-action is urlsessionformatted - result is a post to xyz.cfm;jsessionid=xxx...
Should I open a bug report on this?
Thanks for your help guys!
Joerg, before you file a bug report (which may well be warranted), since you say you applied Update 3 and it didn’t change things, here’s something you want to confirm (and may have missed).
The technote for the update does say that after applying the update, you would reconfigure the web server connectors (which for most means re-run the CF web server configuration tool).
Especially in this case where you have an issue with the web server connectivity, this may be key if indeed it may have been addressed. Of course, it’s not mentioned as being fixed in the technote, but still…
@Joerg Yes, I know the J2EE Servlet specification describes the jsessionid token as delimited by a semicolon (at the time I last read it 6 or 7 years ago). But I did notice that session.urltoken and cflocation addtoken now use an ampersand to delimit jsessionid, and I'm not sure why (more later on that). I would like to just say that in my configuraiton I did not reproduce the issue even with urlsessionformat where a ; was used.
My config was Apache 2.2.15 64bit on CentOS 6.3 (~RHEL 6.3), with CF 10 final. I disabled cookies using Safari and Firefox to test and urlsessionformatted links with ;jsessionid worked ok on that env. Your own environment obviously differs, but I don't have that env to test myself.
The problem as I see is that your Apache server is attemping to parse the URL before the CF Connector tries to. In CF9 and earlier, the connector config file had a setting to make the CF Connector parse the URL first, bypassing the webserver's attempt to parse it. I don't know of an equivalent means in CF10 of forcing the connector to be the only one parsing the URL.
@Charlie, I'm generally aware of the session fixation issue, and have been keeping up with most blog posts and email threads that I found on the topic, but I doubt I've reflected on them as carefully as you have. I've been unable to find any references to the change in the delimiter from ; to & for jsessionid. Perhaps I don't fully understand the issue yet.
Curiously, as an aside, I did notice that the documentation for urlsessionformat() in CF8, 9, and 10 (at least) shows what I believe is an incorrect example of the function result. It shows ...index.cfm?jsessionid=NNNNNNN...;cfid=NNNN=;cftoken=NNNNNNNNNN where the jsessionid is NOT delimited by a semicolon but rather a ? mark. The actual output is ...index.cfm;jsessionid=NNNNNNNNNN... where a ; delimiter is used rather than a ?.
thanks for the tip - of course I didn't read the technote
I removed the connector with remove_all_connectors.sh, edited the apache_connector.sh to my paths and ran it.
Now I have a new connector in wsconfig/1/ , all services start as normally but I can't request a page any more.
apache error.log says "child pid 12547 exit signal Segmentation fault (11)"
Would have been too easy
I can't create a running connector anymore.
Nor by the scripts in bin/connectors/ or by invoking wsconfig directly
@Charlie, ok, my second pass reading your reply makes better sense. I see that you were referring to as to why the jsessionid was changing when cookies are disabled. Got it. I thought you were referring to the change in delimiter.
Hey Steven, as for my reply to you earlier, I was only speaking to your observation that the jsessionid value was changing. It’s about that that this session fixation change is having an impact.
Yikes, Joerg. That’s not one I’ve seen, but then I don’t work much with *nix or Apache.
Here’s a question to help you resolve things, or help others help you: in doing this reconfig of the connectors, was that any different than what you’d done before, when first setting things up? I’m just trying to know (and have others here know) how familiar you already are with configuring the connectors.
I wouldn’t see why, if you’d done them before, and you just added the hotfix, that then running them again would break so violently for you.
I suppose if you can’t resolve it, or someone doesn’t chime in, then in the interest of time it may be best just to reinstall. I’ll understand if you may then be hesitant to rebuild the connectors after applying that update 3, if you think doing so breaks.
Just recovered the old wsconfig.jar from the backup-dir in the hotfix03-folder.
Also realized that there is a hotfix-uninstaller - great!
Back to my old wsconfig.jar I could easily create a new connector and everything is up and running!
I'll now uninstall hotfix 3 completely and reinstall it.
Maybe I'll try a complete reinstall of CF when that still fails.
To answer your question Charlie - The first install of the connector was done by the installer...
My first run of the connector script was after installing hf3.
As the recovered wsconfig.jar prooves - the scripts seem to work smoothly...
I read in the CF-Blog, that there are many Win CF-Installs that fail to start after installing hf3...
Maybe there is a bigger problem with hf3?!
@Joerg, if the connector install script is using verbose -v then did you notice anything unusual in the wsconfig.log to indicate there was a problem? How about trying the -apxs option which will force build a new connector on your system rather than plugging in a pre-built connector. (using -apxs requires package httpd-devel). I've seen Apache seg fault when CF added the wrong connector for my architecture.
the wsconfig.log doesn't show anything noticable...
I have httpd-devel installed, but wsconfig compains about the -apxs switch.
Or don't you mean to run cfusion/runtime/bin/wsconfig with -apxs?
Yes, sorry for brevity. I meant to use the wsconfig tool with the -apxs option which will force wsconfig to build a connector from source and compile it against the libraries on your system for best compatibility. So you set up the commandline as you would normally do (or copy and modify the cmd line from a pre-existing connector install script), then add in the -apxs option, and its best to include the -v option too for maximum output.
/opt/coldfusion10/cfusion/runtime/bin# ./wsconfig -apxs -ws apache -dir /etc/apache2/ -bin /usr/sbin/apache2 -script /usr/sbin/apache2ctl
returns the wsconfig help page, because he doesn't recognize the -apxs switch...
what exact script are you referring to Steven?
Eeeep. My fault. Apparently there is no explicit -apxs switch anymore. It seems that use of apxs to build a connector from source is built into wsconfig now, and wsconfig will determine if it needs to build from source or not, but you cannot tell it to manually do so. On my CentOS, it builds the connector from source each time even though I don't call out -apxs.
Well, it seems like I'm stuck with a machine updated with hotfix 3 and a downgraded wsconfig.jar to hf2...
So my problem still persists...
This is by far the worst expierence I had with ColdFusion for the last 10 years
I just extracted the jar files (hf2+3) and copied the intel-linux64 from hf3 by hand.
Just to eliminate the option that the wrong mod_jk.so is extracted.
But the result is the same - Segmentation fault (11)
Seems like the included mod_jk22.so for intel-linux64 is not working...
Could someone try clicking this link on Apache: <cfoutput><a href="#urlSessionFormat('/')#">home</a></cfoutput>
When J2EE sessions are enabled and cookies disabled, I see that clicking a link to urlSessionFormat('/') triggers a 404 on IIS due to the "/;jsessionid". Does that also 404 on Apache? I'm unfamilar w/ Apache, so I'm curious.
could try replacing usage of #urlsessionformat('somepage.cfm')# with 'somepage.cfm?#session.urltoken#' instead.
I tried this on CF9 and CF10 w/ cookies disabled, J2EE Sessions enabled, and verbose logging enabled in the web server connector. I'm seeing that CF9 properly finds the jsessionid session identifier and does not create a new jsessionid cookie on each request. However, I'm seeing that CF10 does not find the jsessionid session identifier and creates a new jsessionid cookie on each request. Basically, that's not maintaining a session for me in CF10 - while it does maintain session in CF9.
Could anyone verify? My CF10 test was ran on x64 Windows 7, so perhaps what I'm seeing is specific to that connector.
Could someone try clicking this link on Apache: <cfoutput><a href="#urlSessionFormat('/')#">home</a></cfoutput>
my x64 CF10 with update 2 on ubuntu 12 returns this link:
which results in a 404 error by apache... I still hope that this gets fixed in hf3...
I'm seeing that a jsessionid immediately following a forward slash ('/;jsessionid=x') is not treated as '/' by CF's web server connector and therefore an attempt to find a match for URI '/index.cfm' is never made. However, this issue also exists in CF9.0.1. Thus, I haven't yet found a scenario where ;jsessionid causes a 404 in CF10 that didn't already exist in CF9. I've tried tho.
AHA! Thanks Joerg for that clarification! Yes, I wondered if that was the case (jsessionid immediately following the forward slash). However, that also fails for me in CF9. Does that work for you in CF9?
Hmm, I see it was also throwing a 404 for you when jsessionid follows a file (ex: login.cfm;jsessionid=x). Hmm.. I wonder if this issue is specific to the Apache web server connector in CF10. However, I see that Steven verified that he sees the expected result. Well, I'm not yet sure how you're both seeing different results w/ CF10+Apache. Interesting.
I ran into this issue after our upgrade to CF10.
Our applications ran smooth with CF7/8/9.0.1 - after the upgrade to CF10 we began to see those 404 errors...
Hope that Update 3 comes back soon
As we are running some websites for huge customers, we are under constant security testing by a IT-security-company.
When they began to run specific SQL-injection tests, we started to see "JRun unavailable" errors, due to the jrun-connector.
This should be fixed in CF10 - that's why we are upgrading...
Now the security-company suspended their tests until we have our upgrade done.
But as CF10 doesn't work as expected, we are stuck on CF9 - having the security-company at our back waiting to start testing again (as they have to).
A very very unpleasant situation.......
Is your setup the same as you described here? http://coldfused.blogspot.com/2006/09/handling-j2ee-session-with-cooki es_12.html
I found that post when researching urlSessionFormat/J2EE Sessions.
I've logged the following bugs which, when fixed, would help you w/ urlSessionFormat() and J2EE sessions. I'm not sure if any of them will solve the issue you mention in this thread, but they still should be fixed regardless.
3352056 - https://bugbase.adobe.com/index.cfm?event=bug&id=3352056 (CF9 vs CF10 wrt urlSessionFormat() w/ J2EE sessions)
3352067 - https://bugbase.adobe.com/index.cfm?event=bug&id=3352067 (web server connector 404s when URL contains '/;jessionid=x' (jsessionid after forward slash))
3352078 - https://bugbase.adobe.com/index.cfm?event=bug&id=3352078 (CF9 vs CF10 wrt jsessionid in query string (maintained vs broken sessions))
I'm about out of ideas for now.
Hope that helps!,
is there any update on this?
We are running CF10 productive now for about a week with J2EE sessions turned off (former CF9 setup was J2EE sessions ON), to avoid the 404 error.
With this, we are now running into Cookie Problems with our Clients, as the new CF10 Cookies seem to be different to the CF9 ones.
It seems like the session fixation in CF10 may be the cause (?).
I already tried to overwrite the old cookies with expires="now" but this doesn't seem to help.
CF10 cookies are written for ".somedomain.com" and httponly, and CF9 Cookies say "somedomain.com" (without the first dot).
The easiest solution would be to turn on J2EE-Sessions, but there comes the 404 again...
just to let you know:
I added the following to mod_jk.conf and got that 404 error fixed.
The problem is now, that cflocation doesn't seem to pass this through...
When I do a post to login.cfm;jessionid=xxxxxx the user gets logged in.
As I add an cflocation addtoken="true", the session gets lost an the user is back at login.cfm
This seems like an error in the CF10 cflocation?!
PS: Just filed Bug 3430245 for this one.