Webhost turned file() off, coding toasted

vikette

I'm trying to take a rather long piece of JavaScript from another file and convert it into a string/array. Up until yesterday, the following worked perfectly:

$hitbox_string = join('', file($bases.'/templates/hitbox_code.txt'));

Now the server guy's decided to turn off functions like file() and fopen() for security reasons, citing curl and fsockopen as alternatives. I've tried examples of both, plus half a dozen other functions but can't get them to work. I don't even think the curl library is installed on our server. Sacrificing chickens doesn't help much either. Sacrificing the server guy may have unexpected consequences.

Also willing to just paste the JavaScript code into the page calling it, but then I'm still at a bit of a loss with the syntax.

Help me programming gurus! 😕

NogDog

Would it be feasible to change hitbox_code.txt to this:

<?php
$hitobx_string = <<<EOD
...all the current text now in the file...
EOD;
?>

Then you could simply do an include or require of this file, and the $hitbox_string variable would be populated with the text.

NogDog

PS: It might be a good idea to contact your hosting company and tell them that crippling PHP in such a way will be leading you to seek another hosting solution when your current contract expires. 🙂

vikette

Hi NogDog,

That would be lovely, but it doesn't work on this eyewatering mix of html/JavaScript full of interesting characters and quotes to break the string. Some snippets:

<script type="text/javascript" language="javascript">

var _epg=""; 	//event page identifier
var _mn="wp179"; //machine name

if((_bn=="MSIE")&&(parseInt(_bv)==2))_bv=301;function _ex(v){return escape(v)};
var _rf=_ex(document.referrer);_mlc=_pm(_mlc,"",0);_pn=_pm(_pn,"",1);</script>

<script type="text/javascript" language="javascript">_sv=11</script><script type="text/javascript" language="javascript1.1" 
src="http://stats.hitbox.com/js/hbp.js" defer></script>

<script type="text/javascript"
+"&bv="+_bv+"&ce="+_ce+"&ss=na&sc=na&ja=na&sv="+_sv+"&con="+
_ex(_mlc)+"&vcon="+_ex(_mlc)+"&epg="+_epg+"&hp=u&cy=u&dt=&ln=na&cp="+_ex(_cp)+
"&pl=&prc="+_ex(_prc)+"&oid="+_ex(_oid)+"&rf="+_rf;document.write(_x2+_ar+_x3);}
if(_bn!='Netscape'&&_bv>399)document.write("<\!"+"--");</script>"

NogDog

Using the heredoc method of quoting should work regardless of the content and any quotes it contains. Just make sure the "EOD;" (or whatever "end of data" string you'd care to use after the "<<<") is on a line by itself with no spaces/tabs in front of it, and is terminated with a ";".

vikette

I checked the spacing, then broke the document into chunks to see which would work and which wouldn't. The beginning and ends of the document with html comments, JavaScript declarations, variable definitions, and even most of that middle chunk were fine.

But some lines specific caused problems. e.g.

<?
$hitbox_string = <<<EOD
if(_bn!='Netscape'&&_bv>399)document.write("<\!"+"--");</script>
EOD;
?>

<?
$hitbox_string = <<<EOD
var _rf=_ex(document.referrer);_mlc=_pm(_mlc,"",0);_pn=_pm(_pn,"",1);</script>
EOD;
?>

NogDog

Hmmm...they work OK on my PC (PHP 5.1.4).

It almost seems as if it's interpreting the </script> tags as being PHP closing tags (which is not completely illogical since <script language="PHP">...</script> is a valid alternative to <?php...?>). But it behaves fine on my installation. Maybe as an experiment you could try using [FONT=Courier New]<\/script>[/FONT] to see if that makes any difference?

vikette

Hey guess what .... It DOES work on the server. Echo's fine and gives no errors according to the Firefox JavaScript console. It's my PHP editor which is having the issues. In the editor, replacing the <\/script> works perfectly, but that will pooch the page when uploaded.

MarkR

You should contact the hosting provider, explain to them that this kind of configuration change is unacceptable and ask them to refund all monies you have paid for the period on the basis that their service is unusable.

Then you should change to a decent provider who won't do unacceptable changes unilaterally on you.

Mark

vikette

I hear you ... Any business worth it's salt would attempt to amend the situation with profuse apologies and possibly freebies. However, we're at a university, so righteous indignation in the face of Kafkaesque bureaucracy would be met with blinking. :rolleyes:

That being said, however, several websites on the server had been hacked the day before so I think the server guy was under a lot of pressure to flip every switch.

Anyway, it's working now thanks to the quick response from this forum.