[SOLVED] Is php in an external javascript file exposed?

[Neomech]

I'm not sure where to post this question, but I've been reading about using PHP to add some dynamic content to my .js files (and renaming them as .php files), which is something that I could make good use of.

 

I'm planning to do something like described here:  http://www.javascriptkit.com/javatutors/externalphp.shtml.

 

However, my concern is that I'll then have to place this .php file in a directory below my public html directory (where I'd normally have the .js file), which would then be accessible by a user who knew what they were doing.

 

I read somewhere that the php in such an approach isn't visible to the end-user, but I don't understand why.  Isn't it just a .php file that's sitting there in an exposed directory?  I understand that it gets converted to pure javascript when it's being referenced from the html page by the client's browser, but don't I still have php code sitting there in an accessible file that anyone can look at?

 

I guess my main question is:  Is there a way to dynamically generate an external .js file that's "safe" (no PHP can be seen by nosey people)?

 

Thanks!

[sKunKbad]

...but don't I still have php code sitting there in an accessible file that anyone can look at?

 

This is wrong. "Anyone" can not look at this file. If a hacker wants the file contents, they may be able to see it easier being in a public directory, but for normal users, this file won't display any php. Try it yourself.

[Neomech]

Ahh...okay.  You're right.  I seem to be missing something basic then.  Why is that?  Is PHP parsing every file sent to the client automatically?  I guess it is!  For some reason I thought when I was inspecting external .js files I was, I don't know, getting them "differently" somehow (more similar to FTP).

 

Okay, thought that might be a dumb question.....thanks!

[waynewex]

If "hackers" could read PHP code that easily, we'd all be out of business. PHP code is executed on the server's side, not on the client's side. That means that the PHP script executes on the server, performs its tasks etc and then the output of that PHP script (if any - in this case you're outputting javascript) is sent to the browser. There have been instances of PHP code showing up in the browser, but that was only because either the server didn't support PHP or there was an internal server error.

[Neomech]

Yeah, I was aware that web pages were parsed before they got to the client, I just didn't realize that other things (like a javascript file) get parsed as well.  I'm realizing I wasn't really looking at the whole process properly before, and had this daft notion of a "page" that was distinct from a "file".

 

An html page with php in it and a javascript file are both "files" that the browser is accessing via the http protocol, and php is running in the background on the server making sure ANY file accessed over that protocol gets parsed by the php engine first.  Is that basically correct?

[corbin]

As long as the files are parsed, the server side scripting language (in this case, PHP) content is safe inside of them.

 

 

However, there are times when things can go wrong and the code could be displayed to users.  The most well known case of that is probably when Facebook was misconfigured for a short amount of time and their index.php and a couple of other pages got stolen.

 

 

Anyway, what I'm getting at is this: Anything you want to keep hidden, keep it above the doc root and include or require it.

 

That way, if your host misconfigures Apache and it stops parsing .php files or something, your entire source won't be displayed.

[Neomech]

Okay, I think I have my head wrapped around it a little better now.  Thanks for all the feedback

[corbin]