Cron Job Script

[mightymouse3062]

Good Afternoon,
I am working on a website that is currently being hosted by Yahoo. I am trying to setup a cron job that will send emails out every monday. The problem I am running into is Yahoo does not support cron jobs.

I have created a page on another server that redirects to the email script on the site that is hosted by Yahoo and I am getting the following errors:

/home/server/public_html/reservation/generatePermits.php: line 1: ?php: No such file or directory
/home/server/public_html/reservation/generatePermits.php: line 3: //: is a directory
/home/server/public_html/reservation/generatePermits.php: line 4: syntax error near unexpected token `"Location: http://hsr-bsa.org/weekendcamping/admin.php?hl=199f66d3276d32130c87ca3167ba1e3ca03b201a6aac3bc4b463df5a5bccba63"'
/home/server/public_html/reservation/generatePermits.php: line 4: `header("Location: http://hsr-bsa.org/weekendcamping/admin.php?hl=199f66d3276d32130c87ca3167ba1e3ca03b201a6aac3bc4b463df5a5bccba63");'

Here is what I am calling for the cron job script:

/home/server/public_html/reservation/generatePermits.php

What am I doing wrong to cause the error?

Thanks,
Mike

[edited by: dreamcatcher at 7:53 am (utc) on Aug 30, 2010]
[edit reason] exemplified server path [/edit]

[optik]

Changing location is for changing a browsers location, I'm assuming your cronjob isn't been run through a browser on your server so that method wont work.

I've not used curl before but that will probably work for you.

[morehawes]

If your site gets a fair bit of traffic one work-around would be to check if it is Monday (and your preferred time) using the date() function at the top of a script that gets alot of page views and send the emails from there.

Once sent you would then want to log that they have been sent for that week (in a database for example) so they only get sent out once.

[CyBerAliEn]

Let's suppose your Yahoo hosted site is:
http://www.example.com

And the page you want to "hit" with the CRON is:
http://www.example.com/reservation/generatePermits.php

The above PHP page *should* not be a "display" page, it should be a "processing" page. Huh? Your CRON shouldn't be referencing pages that a person would go see/view. If they are, your not likely using your CRON or coding properly. The page you target should perform sort of action or process that starts and completes --- without any kind of action or interaction from a person.

So ideally, your "generatePermits.php" page should, when requested... do whatever is necessary to "generate permits", then terminate. If this were my script, it would do this and only this. Maybe with some simple debugging output, like:

***Generating Permits***
Permits generated successfully!

(etc)

Once you have the script properly coded/etc so it does what you want... the purpose of CRON is to allow you to do some sort of action/task on a recurring timely basis. For example, you could configure CRON to run this script every single Monday, every 10 minutes, every year, etc.

The command you should feed into CRON, try this (but making sure you change the web address as needed):

lynx -dump http://www.example.com/reservations/generatePermits.php

CRON will execute this command everytime it is run. What does it do? It will request and execute the address. Then, it will return anything that is outputted by the web address. CRON, using this command, will then (by default) email this output to the CRON owner. If you setup your script so that it says "permits created successfully", and you want this type of confirmation, then no big deal --- you'll get an email everytime CRON runs with the output of your scrip.

However, if you do not want any emails from CRON and just want CRON to execute this command, adjust the command to be:

lynx -dump http://www.example.com/reservations/generatePermits.php > /dev/null

This will still action (process) the requested web address... but it will "trash" the output, and you shouldn't receive an email. Depending on what you're doing, this might be preferable.

[CyBerAliEn]

I'll add that this type of "configuration" (as you're doing) is NOT suggested as it could open you to potential exploits.

Your configuration is that you have something happening on the Yahoo site... being requested and actioned by another site. There is no authentication here due to the CRON nature (and no real easy/effective way of doing it).

This opens the door to other sites, other servers, other people... manually accessing your web address and "generating permits".

Generally, this is not something you want people to be able to do.

In an ideal situation... your "action" files (things your CRON accesses) and the CRON process would all be on the same server (or within same network setup). And more ideally... you would configure your "action" files in a place like:
/srv/www/mysite/crons/*

Notice it IS NOT inside "public_html"? This prevents anyone from outside the server (ie: the web) from accessing the file. But... your server itself still can! Then, you can put sensitive CRON processes in a secure location and still have direct access for CRON while blocking outside access. And you would then modify the CRON command so that it uses direct commands within the server to parse/execute the PHP file.

[mightymouse3062]

Good Evening,
Thank you for your assistance. I was using /usr/bin/php to try and access the file on the other server instead of lynx.

For the security part, I have all requests go through a single page (admin.php) and I created a "redirect" if the url is admin.php?hl=(64 characters long random string) where it is the only way to access the data. Also, I have it check for the server variable HTTP_USER_AGENT against "Lynx/2.8.5dev.16 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.7a"

Should that be sufficient for the security end?

Thanks for your help,
Mike

[CyBerAliEn]

For the security part, I have all requests go through a single page (admin.php) and I created a "redirect" if the url is admin.php?hl=(64 characters long random string) where it is the only way to access the data. Also, I have it check for the server variable HTTP_USER_AGENT against "Lynx/2.8.5dev.16 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.7a"

For your purposes, this would in all likelihood be sufficient enough. The odds/probability of someone figuring out your "key" is low, and the same is true for the user agent string. However, even though I would classify the configuration as "good enough", it is not ideal, for various reasons.

I'll note first, that your given agent string is what the server reports when lynx goes to request your page. It is not the agent string of your own computer, browser, etc (this is how it appears).

(1) someone could brute force your key --- this not that complicated
(2) someone could brute force your agent string --- not complicated
(3) your agent string, though appearing "unique", is not actually truly 'unique' --- there are other servers out there with the same string
(4) in relation to #3... if your on shared hosting, every other site on your server would have the same agent string
(5) because you're CRON is not on the same server as the page, this request will travel (plainly) over the web... any "sniffing" server, app, etc that your request travels through will capture, exactly, your "unique pass/key/agent values".

(etc)(etc)

All in all... you're likely fine; because your site appears to just issue permits for camping or such. There is nothing outright critical here (ie: bank accounts, private information, etc) and someone isn't likely to hack your site for such reasons.

But these security concerns should be something you're aware of so that you can make appropriate precautions when and where necessary.

So this is not to make you paranoid, but to help you become aware that your "security" is not fool-proof. You could image a plain website page/script as just a simple park (trees, pond, etc) --- anyone can get in. Imagine your precautions as a 6ft fence around the perimeter --- it will keep most people out; but when someone does want it, it won't take much to get in.

[CyBerAliEn]

Also... you notate your agent string in your posts here, as well as your 64-bit random string (1st post).

Please consider revising your "key" string as right now it is publicly compromised. ;)

[mightymouse3062]

Good point.

Thank you for your assistance.

Sincerely,
Mike