RSS to HTML: Why can't my PHP file open remote RSS files?

January 3, 2006 1:59 PM

RSS to HTML: Why can't my PHP file open remote RSS files?

I'm trying to implement the lastRSS parser. I'm pretty sure I've followed the (simple) directions to a T, but no matter which code sample I try, I get the "Feed cannot be read" error.

I know the RSS URLs I'm trying are good -- is there some simple server-side trickery that the directions assume I know about? Some way to allow PHP to grab a remote file?

posted by o2b to Computers & Internet (7 answers total)

lastRSS appears to use fopen() to grab URLs, which can be turned off in the php.ini file with allow_url_fopen.

Check your PHP installation to see if allow_url_fopen is enabled. You may also want to try Magpie RSS as an alternative parsing lib if you can't get lastRSS working, although I don't know enough about lastRSS to say which is better.
posted by revgeorge at 2:13 PM on January 3, 2006

The setting "allow_url_fopen" most likely needs to be enabled.

I cannot find the string "Feed cannot be read" in teh lastRSS code. Are you sure this is a PHP error (and not a Firefox/formatting issue)?

Can we see your page?
posted by null terminated at 2:15 PM on January 3, 2006

Response by poster: I suspect you're both right about "allow_url_fopen" needing to be enabled. I'll get on the horn with the host and make that happen.

Thanks.
posted by o2b at 2:41 PM on January 3, 2006

i ran into problems when i got a dreamhost account. they have file_get_contents() disabled. The workaround is they have curl compiled into php. so instead of doing file_get_contents("url") you do more like:

$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, "$url");
curl_setopt ($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt ($ch, CURLOPT_CONNECTTIMEOUT, 0);
curl_setopt ($ch, CURLOPT_USERAGENT, $_ENV['HTTP_USER_AGENT']);
$file = curl_exec($ch);
curl_close($ch);  

posted by 31d1 at 2:44 PM on January 3, 2006

"allow_url_fopen" = gaping security hole. Your host is smart to leave it off.

Use the Curl method instead.
posted by drstein at 4:11 PM on January 3, 2006

How exactly is allow_url_fopen a security hole when curl isn't?

Don't get me wrong -- I really dig curl, but it's hard to see why fopen would really cause any additional problems.
posted by ph00dz at 5:09 PM on January 3, 2006

If you have any file names that are held in variables, and any of those variables are user-supplied *or* potentially taintable through various variable injection techniques, having allow_url_fopen gives attackers an extra angle.

Example: I wrote a form mail script in PHP a while back. When I first started doing things like this, most form mail scripts either (a) had you specify the recipient as a hidden value in the form or (b) had you modify the script itself to contain the recipient's address. Option (a) was obviously an invitation to get hijacked by spammers. Option (b) is decent, but having people wade through script code seems less than ideal.

So I decided to write one where you could use the form to specify a configuration file that lived on the server. Keeps the data out of the script, keeps the data out of the form, and is therefore secure, right? Well... no. With allow_url_fopen on, a spammer who had figured out my script could exploit it by specifying a configuration file on any location he chose.

I realized this at some point and added some filtering code for that contingency when updating the script against header injection attacks too, but it might still be vulnerable to oddly encoded urls or something like that.

Now, curl has something of the same problem -- but the thing is, the nature of curl is such that the coder has to be aware the script is fetching remote material. The big problem with allow_url_fopen is not that it has that power in particular, but that it's sortof underneath the radar. The person using fopen may not be aware of the remote feature and associated potential trouble, or may not be thinking about it.
posted by weston at 10:14 PM on January 3, 2006