tracker issue : CF-4162390

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

Cannot Store Scheduler Output with .htm./html Extension

| View in Tracker

Status/Resolution/Reason: Closed/Withdrawn/AsDesigned

Reporter/Name(from Bugbase): Mary Jo Sminkey / Mary Jo Sminkey (Mary Jo Sminkey)

Created: 06/08/2016

Components: Scheduler

Versions: 11.0

Failure Type: Usability Issue

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Minor / Some users will encounter

Locale/System: ALL / Platforms All

Vote Count: 2

Issue was previously discussed in ticket 3336106 without being resolved. The scheduler by default will not allow you to write the output of scheduled tasks with an .htm/html extension, only .log or .txt. This is particularly frustrating because these files are NOT typically log files, they are the output of running CFM pages so HTML is a very common output to have. So as developers we have to constantly rename these files with the right extension before we can view them properly. 

While this functionality may not be a good idea to have enabled by default, there needs to be a way to enable it easily, without messing with config files, with a warning to the user about the potential security issue if they use a path to a web accessible location. There seems to be some mechanism in place on the neo-cron.xml file that prevents manual updates to this file now so that manually updating it is problematic to begin with. But manually changing it isn't ideal anyway, it doesn't ensure that the next developer that comes along and sets up their own task would know that they shouldn't save html files from the scheduler somewhere web accessible. It is far better to have this capability handled through the admin for the scheduler in some way so that EVERY time a developer sets up a scheduled task to write out an html file, they are forewarned about the security issues and that they need to be careful about where that file is saved.

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

Watson Bug ID:	4162390

External Customer Info:
External Company:  
External Customer Name: Mary Jo Sminkey
External Customer Email:  
External Test Config: Saving output in a scheduled task to a file with .html or .html extension

Attachments:

Comments:

This is affecting our clients
Vote by External U.
2481 | June 08, 2016 02:50:23 PM GMT
Here is what, you can try:- 1. Stop CF Service 2. Navigate to neo-cron.xml at \ColdFusion11\cfusion\lib\ and take a backup. 3. Open the file with notepad or any text editor. 4. Add "html" as an allowed extension in <string>log,txt</string> and save the file 5. Start CF Service
Comment by Anit K.
2469 | June 08, 2016 02:56:31 PM GMT
Thanks that does seem to work to change the setting. So that will work in the meantime for us, but again, if the issue is that allowing users to write html files to any location opens a potential security hole, this kind of global setting is definitely not the ideal solution versus something that will either only allow html output under the logs directory, or warning/requiring confirmation of saving the output with an .htm/html extension that you are aware of the risks, etc.
Comment by External U.
2470 | June 08, 2016 03:18:38 PM GMT
Voting for same reasons I voted on the original ticket.
Vote by External U.
2482 | June 08, 2016 07:12:38 PM GMT
The option of adding additional file extension is well documented in the cfschedule tag wiki. https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-tags/tags-r-s/cfschedule.html The neo-cron.xml file is relatively small and simple and IMO, is not susceptible to be accidental corruption. As for the forewarning, we can put that up on the wiki page. Don't think it's worth the effort. verified that html output works (after neo-cron is edited) in directories where CF service user has permissions (with 2016,0,02,299200 and CF11,0,09,292480 / Win 7 x64). task_name = "test_extsn_webroot"; cfschedule(action="update", task=task_name, url="http://localhost:#CGI.SERVER_PORT#", interval="ONCE", startdate=now(), starttime=DateAdd("s", 0, now()), file="sch_scriptpath.html", publish=true, path="#expandpath("./")#"); cfschedule(action="list", task=task_name, result="r"); writeDump(r); for(key in "TASK,STARTTIME,PATH,LAST_FIRE") { writeDump(structFind(r, key)); writeOutput("<br>"); } task_name = "test_extsn_extdir"; cfschedule(action="update", task=task_name, url="http://localhost:#CGI.SERVER_PORT#", interval="ONCE", startdate=now(), starttime=DateAdd("s", 0, now()), file="sch_extdir.html", publish=true, path="c:\schd_logs"); cfschedule(action="list", task=task_name, result="r"); for(key in "TASK,STARTTIME,PATH,LAST_FIRE") { writeDump(structFind(r, key)); writeOutput("<br>"); }
Comment by Piyush K.
2471 | June 20, 2016 02:51:09 AM GMT
@Mary - There is a risk with allowing this extension as you have yourself rightly indicated. There is also a workaround here that is well documented. Given the above two, do you still feel there is a compelling case for a fix here?
Comment by Vamseekrishna N.
2472 | July 21, 2016 11:24:54 PM GMT
Yes, because the "workaround" as you call it results in opening up that risk when there are other solutions that would not, such as by default having the scheduler output write only to the log directory or somewhere similar that is not web-accessible, and only allow that to be changed if the extension is not HTML. It's counter-intuitive to say we can't change the way this works because it's a security risk but then be fine with a workaround that creates that very security risk.
Comment by External U.
2473 | July 21, 2016 11:41:52 PM GMT
Mary, Are you suggesting restricting tasks from writing to the web-root altogether, or just putting up a warning in the admin. If one is generating html reports, I'd imagine they'd want it to be web-accessible, rather than just being able to view it offline. Also the warning wouldn't be of much help if the task is being created with cfml rather than with the admin UI.
Comment by Piyush K.
2474 | July 22, 2016 01:28:02 AM GMT
It's hard for me to imagine a situation where I'd be using the output setting in the admin to do something like generate "html reports" that are web accessible. It's certainly not intended for something like that, that's something I would do through the code itself, where I have a lot more control over what it's doing and how it's naming my files. The main reason developers tend to use the output setting is simply so they can see what is output when the scheduled task runs and debug issues that might be occurring. We'll specifically write stuff into our tasks specifically so we can see what happened. As an example my task for solr updates will write out the products that were updated, how many records were updated, etc. This is why it is so frustrating that HTML is not a default option, since obviously MOST output of a running CFM page is html. I don't need that output to be web accessible particularly since unless I'm overwriting it every time I would not even know the file name. Typically what I am doing is just going onto the server and opening up the log files in a browser to see what happened. Frankly an interface similar to what we have for viewing undelivered email would be even more ideal.
Comment by External U.
2475 | July 22, 2016 12:31:06 PM GMT
Based on input from some other CF developers that feel even allowing the scheduler to write to a non-accessible location is a potential security risk, I guess we'll just look at integrating the output into the code when it's needed. Would prefer if there was a secure way to do this through the admin but if there really isn't I am fine with keeping it secure.
Comment by External U.
2476 | July 22, 2016 01:30:55 PM GMT
Mary, For the sake of clarity, let me paraphrase. You are suggesting that there be an admin option (a drop down or combo box, perhaps) that lets one select the file extension type for the files that scheduled tasks are allowed to output to. And the reason it should be done through admin UI, is because it would be more secure (and by secure, I believe you mean, less susceptible to accidental corruption) than directly manipulating the neo-cron config file.
Comment by Piyush K.
2477 | July 25, 2016 07:52:11 AM GMT
If it could be done through the admin in a way that would not open up any security issues, then yes, that would be preferable to having a developer change a setting on the entire server such that someone else might come behind them and write their output to non-secure locations, not realizing that this would have potential for abuse. However, as I mentioned in my last comment, the consensus from some other CF developers is that it may not be possible to do it securely, even if the file output is restricted to a non-web accessible location like the logs directory, and that the best workaround is not to change the neo-cron file but just do your file output in the CF code. So unless you are able to find a secure option, I would withdraw the request. You may at least though want to upgrade your information on the workaround to suggest this option as a much more secure way to do the file output vs changing the neo-cron setting (which I would hardly say is "well documented" on the cfschedule page, it's just barely mentioned in passing without the detailed information on how to make that change and CERTAINLY does not mention that adding an extension as HTML can have such serious security issues....not to mention the important detail that you have to stop the CF server to make changes to that file). Also, reading over that wiki page, it uses this text: "When you create a task, you specify the URL of the ColdFusion page to execute, the date, time and frequency of execution, and whether to publish the task output to an HTML file. " Considering that it doesn't allow output to an HTML file at all, that probably should be changed to just "publish the task output to a file".
Comment by External U.
2478 | July 25, 2016 11:42:32 AM GMT
Thanks Mary, for the confirmation. I'll withdraw this. I've logged a separate bug (#CF-4175528) for the documentation to be fixed. You might want to explore Security sandboxing (CF admin > Security > Sandbox Security) to see if it suites you purpose. You can restrict the access, specific tags or functions have, to selective directories.
Comment by Piyush K.
2479 | July 26, 2016 01:22:36 AM GMT
Sandboxing is a complete separate issue from this.
Comment by External U.
2480 | July 26, 2016 11:40:57 AM GMT