Subscribe: Comments on: RSS to HTML: Why can't my PHP file open remote RSS files?
Added By: Feedage Forager Feedage Grade B rated
Language: English
curl setopt  curl  curlopt  file open  file  fopen  form  lastrss  open remote  remote files  remote  script  setopt curlopt  setopt 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Comments on: RSS to HTML: Why can't my PHP file open remote RSS files?

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

Comments on Ask MetaFilter post RSS to HTML: Why can't my PHP file open remote RSS files?

Published: Tue, 03 Jan 2006 14:13:35 -0800

Last Build Date: Tue, 03 Jan 2006 14:13:35 -0800


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

Tue, 03 Jan 2006 13:59:58 -0800

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?

By: revgeorge

Tue, 03 Jan 2006 14:13:35 -0800

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.

By: null terminated

Tue, 03 Jan 2006 14:15:04 -0800

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?

By: o2b

Tue, 03 Jan 2006 14:41:23 -0800

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.


By: 31d1

Tue, 03 Jan 2006 14:44:43 -0800

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);
$file = curl_exec($ch);

By: drstein

Tue, 03 Jan 2006 16:11:30 -0800

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

Use the Curl method instead.

By: ph00dz

Tue, 03 Jan 2006 17:09:00 -0800

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.

By: weston

Tue, 03 Jan 2006 22:14:38 -0800

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.