Is it possible to make controllers private?

[eluser]jedd[/eluser]
[quote author="BrianDHall" date="1254263194"]
In that case CI/PHP doesn't really know any different than if a regular person visited the address, so protecting such a script from outside use is another matter entirely.
[/quote]

Just so.

My point was that the idea of a regular scheduling tool (cron) does not imply or enforce a tool or method to call that page (ie. /usr/bin/php .vs. a text-based web browser), whereas the decision on the choice of the latter is actually far more germane than the simple and stated requirement to 'run a page periodically'.

It seems to me that the poster is looking to provide some level of security or authentication, without actually implemented a security or authentication system. Were I feeling so constrained, I might opt for the originating IP address (though this obviously fails to scale once you want to manage your cron tasks from a different machine). I dislike maintaining the two separate php.ini files, so I prefer to use the text based web browser approach to launching these pages. Of course, I'd rather not have a cron task at all - if the site is usefully busy, then you can just have a counter or flag such that, for example, every normal user interaction checks to see if it's the first for that hour, and if so, runs off to do the cron stuff. Obviously this fails if you're doing substantial amounts of mucking around every hour, but works if you're just doing a couple of seconds worth of activity.

Alternatively I might implement a simple secure method parameter - and have the method check for the presence of same, bombing out if it is absent. Obviously you can either rely upon a suitably obscure string(s) as your parameter(s), or you can modify them hourly, and have your script look for it in the file system, and correlate that against the URL parameter it receives - a single-use key, if you will.

[eluser]attos[/eluser]
Going a step further... You can have two apps. One accessible from a browser and the other to be executed by a cron job.

The second one would have basic http authentication (.httaccess maybe?) and can be called from wget/lynx/fetch/curl (you name it) with something like:

Code:

http://username:password@localhost/app/

as long as you keep the username and password in a safe location.

[eluser]affix[/eluser]
[quote author="attos" date="1254255015"]This will not work. The $_SERVER['REQUEST_METHOD'] will not be 'CLI'

From the PHP manual:
[$_SERVER['REQUEST_METHOD'] indicates] Which request method was used to access the page; i.e. 'GET', 'HEAD', 'POST', 'PUT'.

Replace your line:

Code:

if($_SERVER['REQUEST_METHOD']!='CLI') {

with:

Code:

if(!isset($_SERVER['REQUEST_URI'])) {

This might do the trick if you're using the command line, give it a try.

This will not work if your cron job uses wget (assuming *nix system). This is because the you would be using something like:

Code:

wget http://localhost/your_app/index.php/Sysadmin/index/

and this sets the REQUEST_URI element of the $_SERVER variable.[/quote]

You could do this if you wanted

Code:

if(php_sapi_name() == 'cli')
{
   //Do Something
}
else
{
     show_error('Sorry you are not Authorized to view this page!', 403)
}

[eluser]jedd[/eluser]
I think coming up with yet more solutions to this problem is pointless, given the bewilderingly frugal attitude our OP has towards explaining his/her requirements and responding to questions.

So far we know 'cron jobs and error reporting'.

Despite asking for clarification on the former, the OP still hasn't revealed if that refers to a /bin/php or a lynx-style call.

No one seems to have touched on the latter, perhaps because it's nigh on impossible to glean any meaning from those words.

[eluser]rvillalon[/eluser]
Jedd,

Sorry for not replying fast enough--I was afk =P. I'm using the cron feature on cPanel with the Cron Job Bootstrapper. Whether it's wget or CLI, I'm not really too sure.

If you have any further suggestions, I'd love to hear your thoughts. My overall goal was to make sure that the controller handling my cron jobs was not accessible through a browser. I figure if it's not meant to be viewed by the browser, there shouldn't be a reason for having it accessible through it.

Alternatively, I could just opt to create a cron job without using CI.

How does everyone go about doing it?

[eluser]rvillalon[/eluser]
It seems to be CLI.

[eluser]jedd[/eluser]
Well, I could go through and summarise all the questions that are pending - and all the ideas that could do with your comment - such as what error-reporting means in this context, whether you have a security/authentication system wrapped around your app already, how secure do you really need this stuff to be, how precisely timed the tasks need to be and how long they'll take to run ... but it seems easier (for me) if you'd actually just look through what's been asked / suggested, and then answer / comment.

I guess we can now add to the list:
o do your required regular tasks match extant controllers' functionality,
o if not, how complex are the things you want to do (say if you authored a non-CI, or even a non-PHP script to run them).

[eluser]rvillalon[/eluser]
Jedd,

I apologize if I've offended you by not responding fast enough or seeming like I've not read through the replies. I appreciate everyone's take on the issue. Also, I have read through the replies, but there just seemed to be a lot of debate.

And to be exact on what I was trying to achieve: My main concern was to make sure the controller could not be accessed through a browser. The controller would be used for cron jobs that clears temporary database entries and user-uploaded images.

I have a website that allows users to add products on my website and images pertaining to those products. I use flash and jQuery for the uploads, and it can be used before products are created. So, if a user uploads an image and abandons the product before committing it to the database, it gets left on my server.

Furthermore, the images are actually stored on a different server, and domain. So having access to the plethora of libraries on CI, , such as the FTP library, really helps make things easier.

Aside from the images, there are other libraries in CI that helps make life easier.

But again, I wanted to make sure that my controllers that handled cron jobs would not be accessible through a browser--and there isn't really a security risk if they were accessed through through it, but I guess it's just personal preference.

Furthermore, let me close this discussion by sharing with you all my solution:

I will be using a combination of php_sapi_name and $_SERVER to restrict controller access. This would ensure that requests can only be made by CLI.

A comment found in the online PHP manual helps explain the reasoning better:

The php_sapi_name() function is extremely useful when you want to determine the type of interface. There is, however, one more gotcha you need to be aware of while designing your application or deploying it to an unknown server.

Whenever something depends on the type of interface, make sure your check is conclusive. Especially when you want to distinguish the command line interface (CLI) from the common gateway interface (CGI).

Note, that the php-cgi binary can be called from the command line, from a shell script or as a cron job as well! If so, the php_sapi_name() will always return the same value (i.e. "cgi-fcgi") instead of "cli" which you could expect.

Bad things happen to good people. Do not always expect /usr/bin/php to be a link to php-cli binary.

Luckily the contents of the $_SERVER and the $_ENV superglobal arrays depends on whether the php-cgi binary is called from the command line interface (by a shell script, by the cron, etc.) or by some HTTP server (i.e. lighttpd).

<?php
var_dump($_SERVER);
?>

Try to call php-cgi binary from the command line interface and then via HTTP request and compare the output of the script above. There will be plenty options to satisfy almost everyone.

For the sake of security remember, that contents of the $_SERVER and the $_ENV superglobal arrays (as well as $_GET, $_POST, $_COOKIE, $_FILES and $_REQUEST) should be considered tainted.

PHP Manual

jedd, thomas, guillermo, narcisha, attos, mattthehoople, attos, brian, affix: thank you all for your help.

Hope this helps someone in the future. :-)

[eluser]louis w[/eluser]
For controllers I only want accessible by cron I just give them a hash key that has to match which gets stored in the config for easy changing. e.g. http://www.domain.com/cron/dosomething?key=123456789

[eluser]Nonox[/eluser]
Hi, I have a question...

How are you executing the controller from the command line? I'm using wget, but $_SERVER["REQUEST_METHOD"] always return GET.

Thanks
NB