NOTE: I confirmed that this appears to be a bug. I just now set up a scheduled task to run tommorrow at 11AM every 1.0 minutes, ending at 11:05 (i.e run 5x). The task ran 5 times today at 11AM.
So, specifically a task set to run every 1 minute for a future date and at a specific start time appears triggers on the current date not the future date.
Let me know if you need additional info. Running Windows 2019 server.
Thank you, this is still a problem. I have had to write a procedure to trigger a gateway task on the local server to convert scheduled tasks from paused to active and then paused again.
Thanks for the quick response. Are you creating your scheduled tasks using the Web Admin, or programmatically?
Just looking to rule out where the problem might be. For us, we create them with code, vs creating them in the scheduler. Wondering if we need to look at the code we are using to create them.
I have no problems with tasks that run every day. They run at the expected time.
The issue is with scheduled tasks set to run once or to start in the future, and only for a limited run.
I believe the bug occurs for web sites NOT running from as localhost… I hypothesize that if one has a web domain (i.e hosting a web site) the program that checks the scheduled task start date cannot “find” the start date (start time seems ok) either because it’s looking in the wrong place or it’s never recorded properly in the scheduled task database. The scheduler falls back to the date of the installation of Lucee(?)
If I am correct, because “now” is always greater than the date of the install, scheduled tasks run as soon as the scheduled task’s time occurs on EVERY day.
That’s my theory.
To get around the problem I trigger a task that runs a coldfusion task to change the task from paused to active. I literally have to click a link from my intranet to start the task manually. I have a process that checks for condition to indicate when the task is complete, and when detected sends a call to change the scheduled task back to paused.
I see the XML, and it updates correctly when one updates the scheduled task’s date, but the date is ignored. It should be easy enough to fix, probably the person who set up the scheduled task processing did not test from a hosted domain on the server, they probably tested only from localhost and said, “yup it works”.
To clarify my earlier response. To get around the problem I have a web utility that I can run whose job is “pause scheduled task 1”, “start scheduled task 2”, etc. by scheduled task name. As long as I re-use the same scheduled task name, this utility can easily enough sit in a web-facing location behind a password protected directory. I can set an alarm on my watch to “trigger task 1” or “pause task 2” etc. Not pretty but it works.
While I am at it, I wish we could turn off the lucee admin or change the default URL associated with each LUCEE admin system for web sites that are public-facing. That’s a big security hole and needs to be addressed as a separate issue asap! I found no way to hide or protect in IIS anyway, because it’s a virtual directory and cannot be password protected at the IIS level.
I am happy to very wrong - but I am “think” - you can just uninstall the CF Admin extension - if thats what you’re after.
“We” dont want it to be accessible from anywhere other than localhost so simply don’t allow the admin URLs from anything other than localhost at the firewall.
To clarify…I need access to a public-facing hosting account admin because only from there can one manage scheduled tasks that are domain specific. https://mydomain.com/lucee/admin/web.cfm
I don’t want to remove it.
I want to be able to protect at the OS level (IIS password) so that I have access to the admin but with an added level of security
I can’t understand… You don’t want to let the admin accessible, but you want to have it accessible to you from everywhere (IP)? From any machine? Sounds more as a decision conflict.
What you need to decide is how far you want to protect that. There are in fact tons of solutions for protecting your Lucee admin, but you MUST decide first WHAT you want to do, I mean in which degree you need to protect it and from where you want to access it. Then reduce the surface of attack to the extend you need.
One common solution (thatt is well documented) would be to block the admin with urlrewrite
completely. From there you can start thinking of how to open a tiny access for you:
E.g.
ssh tunnel to Tomcat 8888 directly (that is what I’d do, using key authentication)
I believe there is a miscommunication. In IIS each time a web hosting account is created by defalt Lucee adds a web-inf directory, etc.
This web-inf directory is a virtual directory that cannot be password protected at the IIS web server level. Without getting into why, there ate times having a domain specific admin (not the localhost version).
Granted the domain-level admin requires a PW for access, I’d like to add an IIS-level password protection too. This helps hide the the version of ColdFusion being used from pen tests. Is there a way to do that? Using Win 2019 server. IIS
Could you please elaborate that? Web-Inf is not virtual, but a physical directory. To get it out of the apps folder, the simplest is to move it out. You don’t need to password protect it in IIS, just move it out by adapting Lucee config like shown here:
You can also protect it in IIS by using a request filter rule. That would be even simpler. Another question is, why do you want to password protect it? There is absolutely no need to access it in any way? In Tomcat for example, the web-inf folder is fully blocked and not accessible.
Lucee is really extremely flexible, we just need to know what you exactly want to do. If you have further questions, please please let us know.
I have been running IIS since NT 3.5 and ColdFusion since version 2. I have managed both Apache and IIS instances of ColdFusion. Lucee works great but there are two issues, one is 401 PW protecting a hosting account’s domain of WEB-INF and scheduling future tasks.
Specific to 401 authentication - In IIS, one cannot set the 401 challenge/response for an OS password to protect the WEB-INF directory. Maybe it’s not “virtual” but it’s clearly structured differently than other directories in a given domain. So without having to explain myself why I want the WEB-INF/lucee/admin/ directory set to 401 authenticate, how does one do this in IIS Windows Server 2019? If you don’t know that’s ok, but please don’t assume I have not tried everything first before kindly asking for advice. Maybe there is an obvious thing I have missed, but I am just looking for someone who has successfully accomplished what I seek to do.
thanks
b
I really didn’t want to be disrespectful, it’s just that sometimes it’s difficult to understand what is being asked for. So, you want to have a Basic Authentication when you hit “https://mydomain.com/lucee/admin/*” like this?
If that is what you want to do, I don’t recommend it. I’d tunnel it with SSH. So, I haven’t much experience with this setting in production. However, here you are… this solution with Basic Authentication MUST have SSL because it sends user/passwords as clear text.
This can be done as with IIS as follows:
Please backup everything first!
Make sure you have the IIS feature URL Authorization installed. If not, install it.
Make sure you have the IIS feature Basic Authentication installed. If not, install it.
In the IIS-Manager go to Request Filtering and add a hiding segment for web-inf to block any possible access to the web-inf folder via IIS. Check that by trying to request a web-inf location through IIS.
Note: Now I’d deactivate mod_cfml valve in Tomcats server.xml and add all the sites/hosts manually, as well as the contexts. That’s because I had some issues with 307 redirects setting this up because of mod_cfml. But that’s just a warning. It may work for you with mod_cfml. But if you experience 307 redirects, add the web contexts in Tomcat manually.
I suppose you have an account/password (with very low priviliges) already setup in windows for the user that should access the lucee admin. Note that, if that user isn’t locked down in your OS, you are widening the surface for attack, since that user is also capable to log into your OS (e.g. with RDP if possible, but also other ways). That’s why I suggest SSH tunnel. You MUST lock that user account down, remove roles and critical groups from that account. I think the best would be to use “iis_users” as user group, but I really don’t know what’s the best to lock that down. There is plenty of material how to achieve it (e.g. iis - How do I create a user account for basic authentication? - Stack Overflow ) but I’d do further investigation.
Open the windows default text editor with admin rights to edit the file: C:\Windows\System32\inetsrv\config\applicationHost.config
and add the following to the bottom, right before the ending </configuration> tag. The settings below apply to the setting I used in IIS in the video! You need to adapt the location paths and the usernames (as you have specified in step 7) accordingly to your setup.
IMPORTANT NOTE: The rules above are the ones I’ve used. Apply the rules above only if you have setup IIS as a default, with all Anonymous Users being allowed globally to request in the URL-Authorization. If you have further rules set up globally or on a per site manner, you MUST verify and maybe adapt these settings, cause there will be inherited rules. That may break your configuration.
Andreas,
Thank you for helping me work this out. I should add that my primary wish for password protection of the admin dir vs. turning off entirely is that I need to set up domain-specific scheduled tasks. It appears (to me) that one can’t set them in the localhost, they have to be set with the domain.
If that is incorrect IN WINDOWS maybe I have a configuration problem, but I cannot for the life of me find a way to reliably schedule a task for a domain (not the local host) for the -future- If I try, the task runs at the correct time but on the current day, the scheduler does not wait (for me using Windows server 2019) for the date scheduled. The date appears correctly in the XML btw - meaning there is an issue between the scheduler and the thing that reads the XML to determine the correct date to run the task.
To return to the original post topic… Scheduler running early, or in my case, immediately on occasion, I think I found the issue at least for us.
History…
Everything ran fine on 5.2.9.x
Upgraded to 5.4.3.2 for security fixes
Scheduled tasks would either run a day early, or in some cases, when the date to run was more than 1 day in the future, the task would run immediately.
And the one thing that may have been unique to this situation was we are in Arizona and don’t observe daylight savings time.
Oddly, setting the Lucee Regional time settings to Pacific (which is the same time as AZ at the moment), and then back to Arizona time solved the issue.
I haven’t done a full server reboot to see if the fix “sticks” past a reboot, but so far things are running fine again.
Did you know that there is an alternative to setting the schedules in the Admin? You can add schedulers programmatically with a simple cfm file. I too usually use the admin in a legacy environment to set scheduled tasks up, but in latest apps I’m doing it fully programmatically, so I even won’t need the admin for that. That makes your app far more portable, and all the schedules will be safe in a backup of your cfc/cfm files. Take a peek and adapt it if you want.
<cfscript>
public query function createMyScheduledTask(){
cfschedule(
action="update"
task="myTestTask"
operation="HTTPRequest"
startDate="1/1/2023"
startTime="4:30 AM"
url="http://localhost:8888/?schedulerTime"
port="8888"
interval="daily")
schedules=getMyScheduledTask();
return schedules;
}
public query function getMyScheduledTask(){
cfschedule(
action="list"
result = "schedules"
);
```
<cfquery name="myTestTask" dbtype="query">
SELECT * from schedules
WHERE task='myTestTask';
</cfquery>
```
return myTestTask;
}
dump( createMyScheduledTask() );
</cfscript>
Another question… I’ve seen issues when using 443 or 80 in the URL of the scheduler. Since the URL has a .cfm template I suppose it’s requesting the same machine? Could you try to request directly to Tomcat to url=“https://www.----.com:8888/tasknamehere.cfm” with port=“8888” ? Could you also setup the start date to be slightly in the future?