I've just recently installed CF11 on a new machine but I'm encountering the below issue when trying to navigate to the localhost directory in a browser.
On my previous machine which was using CF10 I was able to get the directory listings and navigate through folders to specific pages so is it some setting that I am missing?
I can navigate to CFAdmin okay and have added a whole range of aliases in my server.xml file which I can navigate to, as well as adding the CFIDE and WEB-INF ones.
As an aside, I also seem to get that silly 404 badge in front of CFs debug output when I try and navigate to a page that doesn't yet exist. Is there a way to switch it off?
If you need more details let me know.
Thanks in advance
Related
I recently installed CF2018 update 9. IIS is serving the applications I had in virtual directories normally, with the exception of CFIDE. Attempts to access localhost/CFIDE/administrator/index.cfm result in empty HTTP responses, with Content-Length:0 headers. The admin page is accessible through localhost:8500/CFIDE/administrator/index.cfm, which is (I think) just reaching out Tomcat directly. So I am wondering if anyone knows what the culprit for a blank administrator page when served via IIS might be? It worked before the update.
FWIW I have checked the handler mappings and they point to the same DLL as the applications that are properly being served (that is, .../ColdFusion2018/config/wsconfig/1/isapi_redirect.dll).
You need to add a site to IIS first, call it cf-admin or similar.
You need to add a second connector to WCONFIG located here:
/cfusion/runtime/bin/wsconfig.exe (run as admin).
Click ADD
Leave drop downs as they are, changing the bottom one "IIS Website" to the site you just created.
Click OK and OK again to restart
Expand the site in IIS you just created, right click the /jakarta vdir and check the location.
Open (location from above) /uriworkermap.properties
Remove the "!" from last line, so it reads /CFIDE/* = cfusion
Restart IIS and CF.
browse to the host header as configured when you created the site in IIS.
I just deployed a new site, call it SiteA, that uses cftooltip, but the tooltips are not displaying. When I hover over the link, nothing happens. SiteB has been running on the same server for a long time, and it's tooltips display fine. The folders for SiteA, SiteB and CFIDE are all in inetpub/wwwroot.
My browser reports the following when trying to display tooltips on SiteA:
'ColdFusion is undefined'
'YAHOO' is undefined.
It would seem that SiteA can't find what it needs in cfide/scripts, but SiteB doesn't have this problem. In the CF Admin, I have a mapping to cfide.
Any ideas? Thanks in advance for help.
Peter
It's not exactly a solution, but you can cut and paste the CFIDE/scripts folder into the webroot of SiteA, which should at least get it working until you work it out!
Things to check are the mappings (obviously), but also any URL rewriting etc; look into chrome dev tools or firebug to see what is being returned from the missing .js call (i.e is it an IIS or apache 404, or something else?)
I'm setting up a new server (CF10 W2K8) going by Pete Freitag's new CF10 lockdown guide. I have a test site installed and if I bring up www.mydomain.com it loads the default document (index.cfm) just fine. However, if I try www.mydomain.com/index.cfm (or any other specific .cfm page), I get a 404 not found.
IIS logs do record a 404 error. If I create a .htm/.html page it comes up fine.
I had this problem as well. Running on Windows Server 2008 R2.
I found some threads that suggested that I re-run the "Web Server Configuration Tool" that is installed with CF 10 ({cfroot}\cfusion\runtime\bin\wsconfig.exe).
I tried several things including "Add..." using the name of the server (instead of localhost). Then when I removed it (connections using the name of the server), I could see the IIS commands getting executed to remove all of the connection settings. I also removed the localhost connection. However, using "Add..." to attempt to add localhost back never worked.
So, for me, this tool only worked for removing the cfm/IIS settings that allowed CF to work. My next step was going to be a reinstall of CF 10. However, I found a link to this page:
http://helpx.adobe.com/coldfusion/kb/coldfusion10-iis-manual-connector-configuration.html
I followed the instructions on that page with a few exceptions. I didn't need to follow steps #1 & #2. The file (isapi_redirect.dll) was still there. Steps #3 - #5 were verified (the files existed and had the correct information in them). Everything worked after I finished the steps, except document root documents (http://website.com/). All I had to do was add index.cfm as a server-wide "Default Document". Adobe forgot that step in their instructions.
I don't know why the "Web Server Configuration Tool" failed to install on my server. I even tried running it "Run as administrator" with no success.
I did have to add the virtual directories (CFIDE & jakarta) to all the sites on the server as well.
You can use these handy command-line snippets to speed up that process if you have multiple sites to manage:
rem add cfide virtual directory (CF 10):
%systemroot%\System32\inetsrv\appcmd add vdir /app.name:"site.com/" /path:/CFIDE /physicalPath:"{cfroot}\cfusion\wwwroot\CFIDE"
rem add jakarta virtual directory (CF 10):
%systemroot%\System32\inetsrv\appcmd add vdir /app.name:"site.com/" /path:/jakarta /physicalPath:"{cfroot}\config\wsconfig\1"
Just replace the "site.com" and {cfroot} values to work with your server.
When setting up additional sites you must create a virtual directory called jakarta that is mapped to the /config/wsconfig/1 folder
Sorry - forgot to mark this closed. I reformatted and reinstalled everything per the CF10 lockdown guide and it worked that time.
I know one problem I had was mapping a virtual 'jakarta' directory in IIS, but I never came up with a specific solution for the domain.com/index.cfm issue.
Can anyone help with this strange problem.
I have just installed CF10 developer on Win7 which is using IIS7.5.
Installation went smooth, and can browse .cfm files no problem and connect to datasources no problem .. BUT: even though I can browse all my local cf sites, none of the sites will display images or styles for external .CSS files.
So, I get the site, content from the database, and all the functionality of cfm files being parsed OK, but no styles and no images.
If I browse directly (pasting the filepath in the browser) to one of the images I get a 404 error - file not found - even though the .gif file does indeed exist in the directory.
So, basically, I can run CFM files, and browse a local site built in coldfusion, but none of the images or externally referenced css files will be "found" by the browser/IIS.
Can anyone help?
Thanks in advance if someone can..
Sounds like an issue with those mimetypes, please see the following for information on installing the static content role to IIS and enabling those mimetypes to be served.
No Mime Types Option in IIS 7
Be sure to enable static content in IIS 7.
Had two occurrences of this problem lately.
See here:
http://weblogs.asp.net/anasghanem/archive/2008/05/23/don-t-forget-to-check-quot-static-content-service-quot-in-iis7-installation.aspx
Try restarting the IIS server. Close all browsers and restart.
You need to determine if it is a CF issue or an IIS issue. Try the following:
Check to see if this is an issue with images not being served vs broken paths to the images. There may be CFML code that is creating links to invalid locations.
If the locations are valid then it would be an issue with IIS not server image files.
Also check to see if there is a similar issue with JPEG and PNG files. If JPEGs and PNGs show up, this suggests an IIS issue.
Also try creating a simple HTML page that has an image on it. If it has an image on it, this suggests a CF issue
anytime a user logs into our Wiki they get the following error: "This Wiki uses cookies to log in users. You have cookies disabled. Please enable them and try again." Even though the error displays, the user is actually logged in and can make edits as normal. If the user doesn't look closely they can't tell they are logged in and it's causing confusion I would be glad if anyone gives me a hint
Wikimedia's advice is Check to make sure PHP's directory for storing session data is writable. This directory can be found in the php.ini file under the session.save_path setting. Errors in this php.ini setting can also cause other problems.
... (and) make sure the Internet Guest Account (eg. IUSR_FOOBAR, nobody, or apache) has write permissions to the folder listed in the session.save_path variable of the php.ini file.
Source.
If you are using a hosting site you need to edit your php scripting configuration (php.ini). The page should have information on your web document root. If there is already a "tmp" folder created then use it. If there is not a tmp folder in your current set up create one that is NOT browseable by users and tell the php.ini file the location as directed above.
For future reference... We just had a similar problem on Appropedia (same error, but couldn't log in at all). It turned out the temp directory was full. Cleared the temp directory, problem solved.
It turned out the temp directory was full
In my case it was because the entire partition was full, needed more space.
Problem I just had was due to default install of our PHP using C:\windows\temp as a base folder for PHP session and other data.
Of course, once someone empties out the temp folder because its full of junk .... the sub-folders for PHP information go with it too :\
If you are using NGINX + PHP-FPM the previous answers will likely not be of any assistance.
From the command line, run:
php-fpm -i|grep --color cookie_path
See what your cookie_path is, then stat the folder and ensure your php-fpm user has write access to it.
To resolve this issue using Nginx and Php-Fpm, I had to change my cookie_path from it's default of / (seriously, why would this be a default?) to /tmp.
After restarting nginx and php-fpm, it works perfectly.