tracker issue : CF-3783403

select a category, or use search below
(searches all categories and all time range)
Title:

ExpandPath Returns Incorrect Path When Used with Mappings in Application.cfc

| View in Tracker

Status/Resolution/Reason: Closed/Fixed/

Reporter/Name(from Bugbase): Rob Bilson / Rob Bilson (Rob Bilson)

Created: 06/30/2014

Components: General Server

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Major / Most users will encounter

Locale/System: ALL / Mac 10 All

Vote Count: 3

Listed in the version 11.0.03.292480 Issues Fixed doc
Behavior has changed between ColdFusion 9/10 and ColdFusion 11 so that the expandPath() funcion returns an incorrect path to files using ColdFusion Mappings when used within Application.cfc or any component extended by Application.CFC.

Test case:

/
/foo
	foo.cfc
	/config
		config.xml
/wwwroot
	/cf11_mapping_bug
		Application.cfc
		test.cfm

Create a Mapping in the ColdFusion administrator for /foo, pointing to the /foo directory you just created.

Here are the files you'll need:		

<!--- foo.cfc --->
<cfcomponent output="true">
	<cfparam name="xmlConfigFile" default="#expandPath('/foo/config/config.xml')#" />		
	
	<cfoutput>	
	In foo.cfc <br />	
	#xmlConfigFile# <br />
	</cfoutput>
</cfcomponent>

<!--- Application.cfc --->
<cfcomponent extends="foo.foo" output="true">
	<cfset xmlConfigFile = expandPath('/foo/config/config.xml') />	
	
	<cfoutput>
	In Application.cfc <br />	
	#xmlConfigFile# <br />
	</cfoutput>
</cfcomponent>

<!--- test.cfm --->
<cfoutput>
In test.cfm <br />	
#expandPath('/foo/config/config.xml')# <br />
</cfoutput>

<!-- config.xml -->
<foo />

Executing the code on ColdFusion 9/10 results in the following output:

In foo.cfc 
/Users/rbils/Sites/localhost/foo/config/config.xml 
In Application.cfc 
/Users/rbils/Sites/localhost/foo/config/config.xml 
In test.cfm 
/Users/rbils/Sites/localhost/foo/config/config.xml 

Executing the same code in ColdFusion 11 results in the following:

In foo.cfc 
/Users/rbils/Sites/localhost/wwwroot/foo/config/config.xml 
In Application.cfc 
/Users/rbils/Sites/localhost/wwwroot/foo/config/config.xml 
In test.cfm 
/Users/rbils/Sites/localhost/foo/config/config.xml 

As you can see, expandPath when used in Application.cfc or a component extended by Application.cfc results in the mapped path being incorrectly returned.  We expect to see:

/Users/rbils/Sites/localhost/foo/config/config.xml 

But the bug is causing the mapping to be ignored and instead appended to the base path like so:

/Users/rbils/Sites/localhost/wwwroot/foo/config/config.xml 

In the real world, this is breaking all of our mach-ii apps, and requires code changes to work around the problem by providing absolute paths.

----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3783403

External Customer Info:
External Company:  
External Customer Name: Rob Brooks-Bilson
External Customer Email:  
External Test Config: My Hardware and Environment details: Tested on ColdFusionn 9, 10, and 11 on Windows and OS X.

Attachments:

Comments:

I believe this may be related to bug # CF-3713398 which I reported during the beta (and was fixed).
Comment by External U.
11738 | July 08, 2014 09:54:05 PM GMT
This is preventing us from upgrading to CF11, looking forward to an update being released :-)
Vote by External U.
11755 | August 21, 2014 06:12:34 PM GMT
We want to upgrade a set of CF9 servers to CF11 before Adobe's support expires at year end. This issue is causing our apps to fail across all servers. Very keen to see a prompt resolution of this thanks.
Vote by External U.
11756 | August 24, 2014 04:26:13 PM GMT
I have someone hitting this. I see that it's fixed, but is there any way to get the fix before the next official update of CF11?
Vote by External U.
11757 | September 04, 2014 08:17:28 PM GMT
For what it's worth, in tripping over this same bug, I have found two oddities about it: first, if you do the expandpath against the built-in CFIDE mapping, it works fine. It's only if you add your own mapping. Second, I find that if I make the request using the built-in web server it works, but it fails (as per the bug report above) if the request is made via IIS. That makes me suspect it's a bug in the connector. Can anyone from Adobe confirm that? And is there an updated connector DLL that fixes the problem, which we might request? I'll send an email to cfinstal@adobe.com to see, pointing them to this bug report.
Comment by External U.
11739 | September 04, 2014 08:21:21 PM GMT
While CF Admin mappings and per-Application mappings are honored in the CFC constuctor area in CF11 Update 3, there is still a problem best illustrated by a repro case: Steps to reproduce: 1) Create directories c:\foo and c:\bar 2) In CF Admin, create the /mymapping="c:\foo" mapping 3) In Application.cfc constructor area, add THIS.mappings['/mymapping']="c:\bar" 4) In Application.cfc constructor area, see expandPath('/mymapping') returns c:\foo (bad) 5) In CF Admin, delete the /mymapping mapping 6) In Application.cfc constructor area, see expandPath('/mymapping') returns c:\bar (good) 7) Repeat step #3 8) In Application.cfc constructor area, see expandPath('/mymapping') returns c:\bar (good) 9) Restart CF 10) In Application.cfc constructor area, see expandPath('/mymapping') returns c:\foo (bad) Thanks!, -Aaron
Comment by External U.
11740 | November 02, 2014 05:22:47 AM GMT
[subscribe]
Comment by External U.
11741 | November 02, 2014 05:09:34 PM GMT
FWIW, I'm currently unable to reproduce what I saw (in comment on 2:52:47 AM GMT+00:00 Nov 2, 2014) on the latest build 11,0,03,292024(PreRelease). Per-Application mappings aren't (as they haven't been in the past) honored in the Application.cfc constructor area. So, I'm not sure how I saw what I saw in my last comment - but it was probably user error on my part. (it'd be nice if per-App mappings worked in Application.cfc's constructor tho) I do see this ticket is fixed: mappings defined in _CF Admin_ are honored in the Application.cfc constructor area (and they weren't in CF11 Final). Thanks!, -Aaron
Comment by External U.
11742 | November 11, 2014 04:07:58 AM GMT
I've reproduced the issue in my comment on 2:52:47 AM GMT+00:00 Nov 2, 2014. Basically, an unnamed app can cause the Application.cfc's constructor area of any named app to resolve any CF Admin mapping to an arbitrary path. Thanks!, -Aaron
Comment by External U.
11743 | November 13, 2014 09:15:57 AM GMT
So, Aaron: does this need reopening?
Comment by External U.
11744 | November 13, 2014 09:34:30 AM GMT
@Aaron, do be sure that you have rebuilt the connector (and specifically for the site which you're testing, if you may have multiple connectors). My experience a couple months ago was that this was connector related. If you did do it with the connector updated, then bummer to hear that it remains even in the update 3 prerelease you're testing.
Comment by External U.
11745 | November 13, 2014 09:55:51 AM GMT
Hi Adam, I currently believe so.. but, I just wanna do some more testing to be sure. I'll certainly follow-up here later today. Thanks!, -Aaron
Comment by External U.
11746 | November 13, 2014 09:58:25 AM GMT
Hi Charlie, I just re-ran wsconfig for good measure (removed configuration from All IIS sites and then added configuration to All IIS sites) and then restarted CF11 and IIS and the same issue remains. That was actually a good reminder for me b/c I forget when I'd last rebuilt the connector. I can't wait until we can just 'update' the connector instead of removing/re-adding (or at least have the connector auto-backup the connector directory(ies) in case we've updated any files like uriworkermap.properties.. which still doesn't have all the extensions that it needs to have [for example, /REST, in case someone types a REST URL w/ CAPS LOCK on] - but that's an issue for another ticket). Thanks!, -Aaron
Comment by External U.
11747 | November 13, 2014 10:15:54 AM GMT
@Aaron, yep, good points. BTW, I opened tickets about that very problem in the connector tool (it losing tweaked settings). Interested folks should vote up/comment on CF-3783361. See also the related CF-3783364. One last thing, Aaron. While you may well have done the steps, you could still have issues preventing you having the connector properly updated (be sure to "run as admin"). You could also have problems in place now for having forgotten that previously. I help folks with that all the time, including just this morning. To really be sure all's well, you'd want to remove the connector(s), then make sure they're really gone in the wsconfig directory, and its wsconfig.properties, and then (after removing them and before re-adding them) make sure all vestiges are gone from IIS (at the site and server level, for isapi filters and handler mappings, as well as virtual directories added). Then, with that all confirmed as cleared out, add the connector back, and confirm the updated isapi_redirect.dll date and test your CF admin or site. I've helped many people go through this process (in about 15 minutes) and all was better after that, fixing things long-asserted to be "remaining bugs" in CF, which had in fact been fixed, but the problem was really issues of misconfiguration of the connector. I get into some of this (but not all the above, so directly) at http://www.carehart.org/blog/client/index.cfm/2013/9/13/why_you_must_update_cf10_webserver_connector. I ought to do a blog entry outlining the steps above. Have been meaning to. Will make a note to do it perhaps later today. HTH.
Comment by External U.
11748 | November 13, 2014 11:45:48 AM GMT
Hi Charlie, Thanks for your reply and I've voted for your tickets. This issue still exists in the latest refresh. After installing the latest refresh of the update, I did this: 1) Saw isapi_redirect.dll's version was: v1.2.40.0 modified 10/31/2014 7:21pm 2) Ran wsconfig.exe as Administrator and removed from All Sites 3) Ensured wsconfig had both removed config info from wsconfig.properties and deleted the "1" dir 4) Ensured wsconfig had removed config info (ISAPI filters, handler mappings, virtual directories) from applicationHost.config (and web.config for the site in question) 5) Ran wsconfig.exe as Administrator and added to All Sites 6) Restarted CF and IIS 7) Ensured no boxes were checked on CF Admin's "Server Settings > Caching" page 8) Ensured the C:\ColdFusion11\cfusion\wwwroot\WEB-INF\cfclasses was cleared 9) Saw isapi_redirect.dll's version was same: v1.2.40.0 modified 10/31/2014 7:21pm 10) Saw issue still exists: an unnamed app can override the paths to CF Admin mappings (meaning it could potentially steal Admin API login creds) in the Application.cfc constructor of named apps Thanks!, -Aaron
Comment by External U.
11749 | November 19, 2014 11:07:52 PM GMT
This bug fix includes: Mapping defined in CF Admin was ignored in Application.cfc constructor area, expandPath function was returning incorrect path, which is a regression from CF10. Would be great if you can log separate bugs for other issues. (Comment added from ex-user id:nawani)
Comment by Adobe D.
11750 | November 20, 2014 05:35:55 AM GMT
Hi Anuj, Filed as CF-3863476. The fix for this ticket (CF-3783403) allows unnamed apps to override CF Admin mapping paths (/CFIDE). All apps (including named apps) then use the overridden path in their Application.cfc constructor area. (issue didn't exist in CF11 Final but is new to CF11 Update 3). Thanks!, -Aaron
Comment by External U.
11751 | December 06, 2014 08:11:53 PM GMT
"(/CFIDE)" should've been "(including /CFIDE)"
Comment by External U.
11752 | December 06, 2014 08:12:48 PM GMT
Hi Anuj, I filed CF-3863476 as you requested here. However, I'm unable to view CF-3863476. Can CF-3863476 please be made visible for commenting/voting? Or is it hidden b/c of the security risk? More importantly, was CF-3863476 ever fixed? If so, in which update? Thanks!, -Aaron
Comment by External U.
11753 | August 17, 2015 07:10:58 AM GMT
*bump* What build was security risk CF-3863476 fixed in? Thanks!, -Aaron
Comment by External U.
11754 | November 24, 2015 12:34:55 AM GMT
*bump*!!!! Adobe! It looks like you may have broken resolution of "/" in certain scenarios when fixing CF-3783403 and/or CF-3863476. To help me, could you please answer above question: "What build was security risk CF-3863476 fixed in?" Thanks!, -Aaron
Comment by Aaron N.
28997 | June 05, 2018 07:11:09 PM GMT
Note: Adobe confirmed in Slack that CF-3863476 was fixed in CF2016 Final.
Comment by Aaron N.
28998 | June 05, 2018 08:55:43 PM GMT
*CF2016 GM
Comment by Aaron N.
28999 | June 05, 2018 08:56:22 PM GMT