Hi All, I have a directory outside of wwwroot that...
# cfml-general
h
Hi All, I have a directory outside of wwwroot that I want to setup as a virtual directory so that coldfusion can still read and write to it as if it were a regular directory. For windows I created a virtual directory in IIS and also added a mapping to it in CFAdmin. The issue is that when i access cfc inside the virtual folder via a remote invocation call (cfc function access="remote") the application and session scopes don't seem to be available even though im calling using the browser where the session is being maintained. Anyone know how to address this?
b
Check your permissions. In the Windows operating system, the virtual directory being mapped to through IAS needs to have permissions set so that the windows account that the cold fusion server agent runs as has full read write permissions
m
I would like to advise caution when directly exposing folders that are being dynamically written to, as this can create potential security vulnerabilities. To mitigate this risk, I recommend serving dynamic files, such as attachments and images, through the application using
cfcontent
. This approach helps ensure a more secure handling of file access.
r
I would suggest to switch from ancient scenarios (access="remote") in favor of some modern framework
h
Thx for the suggesstions. CF is running under the local system account and it does have the proper permissions on the folder that is being virtualized.
b
I would assume this is because the lookup for an Application.cfc file is based on the physical path on disk, not the virtual path
And I would also assume your external folder living outside the web root has no Application.cfc file in it
h
Yes the external directory doesn't have application.cfc.....is there any workaround to get this working?
q
@Harkirat Singh -- Put an application.cfc in your directory that you created the virtual mapping for. All the application.cfc needs to have in it is extends="c:\path\to\your\app.cfc"
Copy code
component extends="../../webroot/Application"
{

}
1
h
that works thx! The issue now though is that i am storing common code in the virtual directory that is being reused across multiple apps so is there a way to have the application.cfc in the virtual folder customize itself based on the calling app so that it only extends the application.cfc of the calling app?
q
Not really a way I would do it... In ACF, the real key to how it knows what application is associated with a file is the application.name field (exposed via the this.name in the application.cfc). In /theory/ you could do some sort of switch statement to attach that applcation.cfc file to the other application. You will run into weird bugs. I don't think the application methods (onApplicationStart, onSessionStart, etc) will fire, but I'm not certain.
e
almost feels like you would need to pass the current application and session scopes as vars into the common code methods, but agree with other comments this seems a potentially troublesome path. Might want to consider just duplicating the common code into each site and having your build/deploy process automate it. or if absolutely have to do it this way, could create symbolic links in windows within each site folder pointing at the the common
h
I found a way to do it by storing the app config in an xml file and reading the same file in the application.cfc of the virtual directory and the main app directory. However I agree this approach is not ideal so im just not storing any cfc in the virtual directory that needs access to session or application scopes and if i need some parameter from the main app in the cfc them im simply passing it in the init method.
b
In reality, this is a problem a framework helps solve, even if it's a custom one
You need a front controller pattern to help consolidate the application creation
Your issue stems from the fact that the initial requests are first hitting a file in the virtual directory. If all requests hit a front controller in the web root (like
/index.cfm?event=foo.bar
or
/index.cfm/path/info/here
and then you included the functionality from your common folder, you would have more control
Sort of like how the "external" locations for handlers, layouts, views , and modules in ColdBox work.