Following: http://help.adobe.com/en_US/ColdFusion/9.0/Installing/WSf01dbd23413dda0e-3f89e8d411fae637e44-8000.html
I already commented out the RDS in \JRun4\servers\[name]\cfusion.ear\cfusion.war\WEB-INF\web.xml
However, the RDS tab is still there in the CF Administrator, and browsing to a CFC still redirect me to /CFIDE/componentutils/cfcexplorer.cfc
How to disable "Component Browser" in ColdFusion?
Thanks
If you don't want your CFCs to be browseable, don't put them in a directory that's browseable! Only files you intend to be browseable ought to be exposed by the web server.
I think the problem here is not the CFC explorer's functionality, it's that you've got stuff you don't want to be browsed to in a browseable location.
The "Component Browser" cannot be disabled--it is a hard-wired function of ColdFusion, which automatically fires when you make a web request to the full location where a .CFC resides--and is unrelated to RDS, whether it is enabled or not.
You will have to decide upon a methodology that you want to approach to prevent direct access to your CFCs, and implement it that way, instead. Such options are:
Disabling the "auto-documentation" of a CFC, as described in the post provided by Henry above (Source: Ray Camden).
Remove the /CFIDE virtual mapping from any of your public facing websites, so that a direct .CFC web request results in a HTTP 500 (as cfcexplorer will no longer be accessible).
A slicker option altogether is to make your public-facing websites use a different virtual /CFIDE directory:
Remove the existing /CFIDE mapping for your public-facing site (#2 above)
Create a new folder in your public facing site called "CFIDE".
Within that directory, create a folder called "componentutils".
, 4. Within "componentutils", create a single file, "cfcexplorer.cfc", which you will then use to make a single call, and return a 403 (Forbidden) code to the browser:
<cfheader statuscode="403" statustext="Forbidden" />
This option is good, because you not only hide your CFCs from direct access via the implicit functionality of the Component Browser, you also hide your CF Administrator from the public (which many CF sites often forget about).
Can't you just delete/rename the cfcexplorer.cfc?
Related
I see an error using CFCHART with Lucee. Same code works in CF. But in Lucee it try to refer to a file graph.cfm in a folder lucee.
mytestserver.com/lucee/graph.cfm?img=026f01d7b8c85b891a9c35c102623747&type=png
Do I need to create any mapping? Should this mapping be in Lucee admin or in IIS?
The short answer is: No, you don't need to add any additional mapping in IIS, nor in Lucee or Tomcat.
I've seen this question here for too long, so I'm placing an answer here to shed some light into Lucee's graph.cfm.
Some tags in CFML need to create additional image files to later embbed them as an inline HTML element into the reendered output altogether. Examples for such file creation are <cfimage type="captcha" ...> or like you have already noted in your issue, <cfchart>.
For such functionality Lucee needs to create these files temporarily somewhere and also make them publicly available. To achive this for cfimage/cfchart, Lucee creates the files in the web context folder of your webroot (which typically is located at path-to-your-webroot\WEB-INF\lucee\temp\graph ) and embbed them inline with a link to graph.cfm. The template graph.cfm just reads the temporary file from that folder, and delivers it in realtime to your application.
If you want to take a look into Lucees original graph.cfm, we can take a peek thanks to OpenSource:
source of Lucees graph.cfm at github
In order to make the files and the template graph.cfm temporarily publicly available, which by the way sits behind the WEB-INF folder ( which is also hidden/blocked by default in Tomcat for securtiy reasons), Lucee MUST have a virtual mapping. But you don't need to set it up, because these are already set up by default. You can see this in the image below taken from the "Mapping"-section of Lucee Administrator:
Because graph.cfm is a .cfm file, IIS will redirect the request directly through the implemented CFML connector ( probably Boncode Connector ) per AJP to Tomcat. Thus you don't need to set any mapping in IIS neither.
Because you have not submitted any additonal error information, such as http error codes or stack traces, I don't have any clue of what might be the cause of your error. It may also be some incompability issue which might be addressed if you submit it to the Lucee core team.
Another possibility is that many installation guides advise you to lock down the "/lucee/" path with IIS URL Rewrite Module, because this is also the path where the Lucee Administrator sits behind. If so, you can change the setting in IIS Rewrite Rule and adapt the rule in such a manner, that it would not block the graph.cfm.
It's also important to note that many of these cftags are implemented as Lucee extensions (.lex files). These are not necessarily pre-shipped or pre-installed in Lucee, but you may install it within Lucee Administrator or get them from Lucees Download site and upload it through your Lucee Administrator in the "Extension" section.
I've just encountered this too. Issue being though the the default mapping still don't navigate to "graph.cfm" so we've added an IIS virtual mapping instead.
By default, Brave is blocking all 3rd party cookies, which is fine, however, I want to work on a local project which uses LocalStorage but I get the following error.
Uncaught DOMException: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
I don't want to turn 3rd party cookie blocking off, which does circumvent the problem, but I'd rather just whitelist local file access (doesn't allow whitelisting file:// protocol).
Is it even possible to get this working without turning off the global "block all 3rd party cookies" setting?
There is 2 ways you can achieve this. Probably also depends how you run your project. I use VS Code and when I run my projects in Brave I got that error. My files were just in a dev directory not in the wwwroot directory.
First option (recommended in my opinion)
Go to: Setting->Additional Settings->Privacy and Security->Site Settings->Cookies
In the "Allow" section add: "localhost" and "127.0.0.1"
Second option (not recommended, as you also stated you don't want to do this)
Go to: Settings->Shields->Cookie Control
Select "Allow all cookies"
Hope this helps
You can whitelist file:///* in brave://settings/content/cookies
Sadly it doesn't seem possible to make this rule more specific to only allow some local web pages access to cookies. And even worse, all local web pages share cookies with each other.
But for testing purposes it should be fine.
Obviously it would make more sense to setup a local web server though.
I have a few related selects that work perfectly on a testing server with very loose security (basically just a simple default install of CF 10).
I have tried to implement the CF 10 lockdown guide on the production server and all seems well, except that related select don't work. That is, the first select in the chain doesn't populate and therefore, none of the related selects populate either.
I even recreated Ben Forta's art media example: perfect on the testing server, no triggering in production.
All other CFC functions seem to work: SELECT and INSERT queries are just fine. Only CFSELECTs with bindings are hosed. I pretty sure that the problem is a server configuration. The same pages worked just fine on our old CF 9 box. Any ideas would be helpful.
My advice to you would be to NOT use cfselect or any other UI stuff in ColdFsuion - It only causes more headaches than it gets rid of.
That being said, if you followed the lockdown guide, you should have limited access to the CFIDE directory - which is needed for any of the ColdFusion UI stuff. There is an option in CF Admin to use a 'custom' path for the scripts ColdFusion uses - it is on the main Settings page. Set this value and create a virtual directory in IIS with the same name pointing to the {cfroot}CFIDE/scripts directory.
I have a handful of users on a server. After updating the site, they don't see the new pages. Is there a way to globally force their browsers and providers to display the new page? Maybe from settings.py? I see there are decorators that look like they do this on a function level.
Depends on browser and cache settings.
There may be no way to tell browsers to do so (as pages are cached, they are not even talking to server, so there is nothing You can do there).
Good trick is to set Vary: Cookie header, so You can always invalidate cache (by changing cookie somewhere) in case of need.
One way to force the browser to load a new page rather than loading the cached version is to change the file name. You could add a date/time to the file name and use a rewrite rule (assuming Apache web server here) to get the new page.
This site gives a quick explanation: http://www.askapache.com/htaccess/mod_rewrite-fix-for-caching-updated-files.html
and google will show many more.
you may also have to examine your cache control headers.
Preface
We are providing customers with our service API.
Each customer has own subdomain (e.g. sergii.ourwebsite.com) and own WSDL URL, it looks like http://sergii.ourwebsite.com/api/bsapi.cfc?wsdl
Also, all the websites (including API, of course) using the same codebase.
Problem
Say, two applications on same CF-server. This can easily happen, because some of customer websites are hosted on our servers.
Both trying to use own API WSDL, say:
http://sergii.ourwebsite.com/api/bsapi.cfc?wsdl
http://galashyn.ourwebsite.com/api/bsapi.cfc?wsdl
And here come the problems.
When second website tries to register the web-service, CF throws an error:
Name:
https://galashyn.ourwebsite.com/api/bsapi.cfc?wsdl.
WSDL:
https://galashyn.ourwebsite.com/api/bsapi.cfc?wsdl.
org.apache.axis.wsdl.toJava.DuplicateFileException:
Duplicate file name:
/opt/coldfusion8/stubs/WS1985941973/api/Bsapi.java.
Hint: you may have mapped two
namespaces with elements of the same
name to the same package name. It is
recommended that you use a web browser
to retrieve and examine the requested
WSDL document to ensure it is correct.
If the requested WSDL document cannot
be retrieved or is dynamically
generated, it is likely that the
target web service has programming
errors.
Problem is that both of them are using same WSDL namespace, built from CFC path:
<wsdl:definitions targetNamespace="http://api">
Current solution
The only working solution for us is using the CFC aliases, like:
http://galashyn.ourwebsite.com/api/v1n1/bsapi.cfc?wsdl
http://galashyn.ourwebsite.com/api/v1n1/bsapi.cfc?wsdl
Each this CFC extends the parent like this:
<cfcomponent output="false" extends="api.bsapi">
<!--- this component used to extend base api version 1.x --->
</cfcomponent>
They produce different namespaces, which can be used without problems -- own namespace for each application:
<wsdl:definitions targetNamespace="http://v1n1.api">
<wsdl:definitions targetNamespace="http://v1n2.api">
This is pretty dumb workaround, but it works for now.
Other solution would be to use the single API sub-domain and identifying the customers by some key (we are already using them for security purposes), but it has serious negative problems for us because of some legacy code.
Please note that I don't know Java, so many specific advices are not so clear for me.
Google shows that this problem exists for years, but I can't find the smart solution.
So maybe here?
I can not "place the WSDL at a common URL for all customers" for now and I've explained why: because I have to use the sub-domains. If you know the way to put the WSDL at one URL and make service requests to another -- please tell me.
A WSDL is just an XML document that describes the web service. You can write (customize) it using CFML. For instance:
http://subdomain.domain.com/api/wsdl.cfm?api=bsapi&customer=subdomain
Then just copy the WSDL generated by CF, and use it as a template for your custom WSDL page. Replace the parts of the WSDL that are subdomain-specific and return the XML document. Be mindful of whitespace (perhaps see CFSilent, CFSetting), and consider using CFHeader to set the mime type to "text/xml".
Do all the customers use the same WSDL? Then place the WSDL at a common URL for all customers.
I also think you need to find out exactly what the error message means. I don't see where it has anything to do with the URL being used. If it had mentioned the URL of another customer, I'd have understood.
Part of this may be due to my lack of understanding of how CF works. In particular, what is this "registering web services" that triggers the problem when two customers do it?
Did you realize that the URL in the <soap:address/> element in the WSDL is only a hint? In many clients, it can be overridden. In a .NET client, just set the Url property of the proxy class. This should allow you to have a single WSDL at a single location, and yet have your customers each reference the proper subdomain, assuming there's some way to convey that information to them. For instance, if there is a way for you to know which customer is making the call, then perhaps you could receive calls on one URL and then redirect to the proper URL, or else use a SOAP Routing infrastructure to route to the correct one.
I hope you are not changing the namespaces from one customer to another. Namespaces have nothing to do with URLs, even if they happen to look like URLs.
There is a namespace attribute for the cfcomponent tag. You should be able to use this, along with cgi.host_name (? I'm at home, without docs) to specify a namespace that matches the subdomain being queried.
Something like:
<cfcomponent namespace="http://#cgi.host_name#/api/v1n1/bsapi.cfc">
Have caught this error message when tried to CFINVOKE webservice from localhost by test script located on same localhost (but in different folder). Sounds 'buggish' for me.