@jochem: Thanks for the follow-up....
>You have one set of settings and one password per CF instance. That does
>not mean the templates are the same ones.
I'm reasonably certain that the templates are the same; there is only the one
CFIDE folder on the entire server located at c:/cfusionmx7/wwwroot/CFIDE, while
all of the Web sites on somewhere below d:/ -- we've make sure that no other
CFIDE folder exists and that none of the Web sites other than the
server1.my.com Web site has a virtual folder called CFIDE.
>> 4. It /appears/ that when IIS sees that a .cfm file has been requested via
>> site1.my.com (or any site), it is handing that request over to the CF
>> without any examination of whether the file and path requested actually
>> Once handed over to the CF app server, the CF app server is seeing that it
>> the /CFIDE mapping (which can't be changed or removed in the CF admin) and
>> continuing to process it.
>I don't think so. The mapping should be used for translating internal
>CFML constructs (cfinclude, cfinvoke etc.), not for translating a path
>from the webserver.
I agree, but that's not the behavior we are seeing, and see below for one
additional item we've tracked down that would seem to indicate that this is
really what's happening.
>Do you have any occurence of the CFIDE folder anywhere under the install
>dir of ColdFusion?
As noted above, the /only/ occurrence of the CFIDE folder is within the CF
>> The only solution we've found so far is to create the CFIDE virtdir under
>> site in IIS's admin interface and then restrict access to the Administrator
>> folder under that to localhost or something like that (with the obvious
>> exception being the server1.my.com site, which is the only CFadmin
>> want and is already configured and restricted).
>Have you tried moving the Administrator somewhere else then in the CFIDE
We haven't tried this.
We found one additional approach to solving this, and it seems to substantiate
the idea that the CF app server is "helping" in a way it shouldn't: within IIS,
you can edit the properties for the various file types, and tell IIS to check
to ensure the file exists. When we turn this setting on for the .cfm files for
the site1.my.com Web site and then try to access the CF admin interface via
site1.my.com/CFIDE/Administrator/index.cfm, IIS hands back a 404 error -- as
well it should. The requested file is not physically present nor is there a
virtual mapping for IIS to get to it. That would seem to indicate that the CF
engine itself is responsible for serving it up, which in this case, it doesn't
seem like it should.
At this point, then, we've identified two approaches to removing access to the
CF admin for all these sites:
1) Create the virtual directory and restrict access by IP
2) Leave the virtual directory absent and turn on existence checking in IIS
Neither of these feels optimal, as they are something that has to be done on
every site that currently exists, as well as remembering to do them for each
additional site deployed there in the future.
It still feels to me, the more we've wrestled with this, that CF shouldn't be
serving it up in the current configuration (no virtual directory and existence
checking disabled in IIS, which also gives us the advantage of using our
missing template handler in CF).
I'm not sure if I've answered your questions, or whether what I've offered up
here as the two approaches to resolving this makes sense. As I indicated,
neither seems all that great...