Ah, yes. In that case I'll agree.Quote:
Originally Posted by Mike
Were the two grammatical errors in that sentence deliberate irony? :)
Printable View
Ah, yes. In that case I'll agree.Quote:
Originally Posted by Mike
Were the two grammatical errors in that sentence deliberate irony? :)
LMAO. :D Thankfully I don't do it so often on Usenet. At least I have the opportunity to edit my posts, here.Quote:
Originally Posted by Twey
Mike
Should hope so :)
Twey, those are some very good points.
For a bit more info about my situation, a main part of my site is a forum and the other forum administrators and I have the passwords for the ftp as well as other things... and would have the passwords for anything that I add.
I just played with stuff a bit more, and I'm really happy to have figured out an easy make to make things more secure. We have an admin control panel as part of the forum (this wasn't coded by me, obviously... it's IPB) and that is totally secure, as far as I can see. I'm putting all of my custom stuff in there right now and using the same verification stuff that it uses... basically checking for an 'admin session ID' and that is checked out by complex code that will either display or not display the pages I'm adding. (the individual pages won't function.... display an error, unless you have a verification code from the page they're included on)
The include thing makes sense now. Glad to know it :) Thanks.
Mike, though I really have no way to respond to the techincal aspects of what you just said, I will point out the major advantage of php:
C++/C/whatever is NOT net based. It has to be on your computer, probably as an .exe or whatever.
Java, while it can be net based (or local, as an .exe), requires plugins and other annoying things. It may have more options and be 'better', but its also a compatibility issue. In fact, one of my computers won't run java. I've tried to install it, but it just won't work. I figure if I can't view my own stuff, then I can't assume others will.
PHP on the other hand is completely server side-- it outputs html. If you have ANY browser, it's compatible with PHP.
In short, php works for what i'm doing. It's pretty easy to get used to, and I like it. Sure, its confusing at times, but isn't all programming?
It doesn't need to be...Quote:
Originally Posted by djr33
...and no, it doesn't.Quote:
It has to be on your computer [...]
I could write a C program (or any other language that can perform stream I/O) that conforms to the CGI/1.1 specification and point Apache to it. When a visitor requests the appropriate resource, the server will execute that program and return its output to that visitor. This is precisely what (CGI) PHP does, except you (the PHP developer) don't need to be particularly aware of it.
Though what I just described is perfectly feasible, especially as there is guaranteed to be a prewritten CGI framework somewhere for many languages (though one would use Servlets with Java, not CGI), it would be difficult to deploy in many situations. Most hosts don't permit their customers to make the configuration changes that would be necessary.
You don't seem to understand how browsers and PHP interact. As I mentioned in a previous post, the server doesn't deal with PHP directly, and neither do browsers. The server envokes third-party code - either the PHP CGI executable, or ISAPI module - that executes the PHP script on its behalf. The PHP interpreter then returns the result of the script to the server, which in turn sends it to the browser. As far as the latter is concerned, it's a completely transparent process.Quote:
If you have ANY browser, it's compatible with PHP.
Mike
which is precisely why php is better. You type php, it works. no need to reconfigure the server.Quote:
it would be difficult to deploy in many situations.
I do, which is precisely why I saidQuote:
You don't seem to understand how browsers and PHP interact.Quote:
If you have ANY browser, it's compatible with PHP.
I don't mean that they are actually compatible, but that they don't need to be.Quote:
If you have ANY browser, it's compatible with PHP.
With java, the browser needs to be compatible. With php, there is no issue... it sends the browser html.
Sorry, but that's complete and utter rubbish :) In most popular *n?x distributions, yes, all you have to do is use your package manager to pull down Apache and mod_php. However, the utter nightmare I had trying to work out how to get PHP working on someone's Windows machine here on the forums...Quote:
You type php, it works. no need to reconfigure the server.
Bad phrasing, I fear. But you're right, if that's what you meant.Quote:
I don't mean that they are actually compatible, but that they don't need to be.
Any server-side CGI script will send the browser HTML. I don't think you quite understand the uses of Java: applets (which you seem to be thinking of) are only one usage. It can also be used to write stand-alone programs, that have nothing to do with the web browser. One of these can be executed on the server in the same manner as any other CGI program, which will return HTML, which can be sent to the browser. See Mike's:Quote:
With java, the browser needs to be compatible. With php, there is no issue... it sends the browser html.
Java is capable of performing stream operations; therefore, it can be used to write a CGI program. In fact, Java provides several different methods of doing this besides being used as a plain CGI program; the developer can also (in an appropriate environment) use servlets , a seperate API designed to replace CGI, and JSP, a PHP-like method of embedding class output in an HTML page.Quote:
Originally Posted by Mike
It would be just as hard if not harder to install another language. My host (and MANY others) have php setup for us right from the beginning. Nothing to deal with there.
well... I don't know that much about other uses of java.
Anyway... there are obviously ways to do this. I'm just saying php is easier than those, if for nothing else than not having to set it up.... at least in my particular situation, with a host that already does it.
Whatever... use another language if you want.
Not trying to say its bad too... they MAY be better.
Just not as convenient.
to sorta get closer to the original question. Is there a way to protect php source files from being read from the php server?
For example lets say you have your index in the root directory and a plugins directory. You want to give particular people access to modify plugins but not to the index. Whats to stop them from reading the index file in and getting the source.
Is there any way to stop this? If there is no way to change the permissions or something on the file all i can think of is overriding all of the file opening commands to exclude the files you want to protect. However this is flawed and crap anyways.
Please advise :D
Any help appreciated :D
Ha. This thread is old. But now I can answer the questions. "...circle is now complete" :p
Anyway...
With a standard configuration, no. PHP has a certain level of access, and that's it.
You might be able to configure your server differently, though.
Are you running your own server or on a hosting site? Ask your host if possible.
Really, giving access to the PHP code at all on the site is a bad idea.
The only way it would make any sense would be to have them submit a form that would verify the contents of the new PHP then update it or, even better, have a human take a look ;)
Remember, though, that there are lots and lots of ways, once any direct access to the script is allowed, to get around any potential blocks.