PHP

2006-03-20T22:13:00.001-08:00

HTTP Authentication

The HTTP Authentication hooks in PHP/FI are only available when it is running as an Apache module. In an Apache module PHP/FI script, it is possible to use the Header() command to send an "Authentication Required" message to the client browser causing it to pop up a Username/Password input window. Once the user has filled in a username and a password, the URL containing the PHP/FI script will be called again with the variables, $PHP_AUTH_USER, $PHP_AUTH_PW and $PHP_AUTH_TYPE set to the user name, password and authentication type respectively. Only "Basic" authentication is supported at this point.
An example script fragment which would force client authentication on a page would be the following: if(!$PHP_AUTH_USER) {
Header("WWW-authenticate: basic realm=\"My Realm\"");
Header("HTTP/1.0 401 Unauthorized");
echo "Text to send if user hits Cancel button\n"
exit;
} else {
echo "Hello $PHP_AUTH_USER.

";
echo "You entered $PHP_AUTH_PW as your password.

";
}
>
Instead of simply printing out the $PHP_AUTH_USER and $PHP_AUTH_PW, you would probably want to check the username and password for validity. Perhaps by sending a query to a database, or by looking up the user in a dbm file.
Watch out for buggy Internet Explorer browsers out there. They seem very picky about the order of the headers. Sending the WWW-authenticate header before the HTTP/1.0 401 header seems to do the trick for now.
In order to prevent someone from writing a script which reveals the password for a page that was authenticated through a traditional external mechanism, the PHP_AUTH variables will not be set if external authentication is enabled for that particular page.
Note however that the above does not prevent someone who controls a non-authenticated URL from stealing passwords from authenticated URL's on the same server. The PHP_AUTH_VARS define in php.h can be undefined to make sure that these variables will never be set and thus disable anybody from using mod_php to try to steal passwords.

2006-03-20T22:13:00.000-08:00

Running PHP/FI from the command line
If you build the CGI version of PHP/FI, you can use it from the command line simply typing: php.cgi filename where filename is the file you want to parse. You can also create standalone PHP/FI scripts by making the first line of your script look something like: #!/usr/local/bin/php.cgi -q
The "-q" suppresses the printing of the HTTP headers. You can leave off this option if you like.

2006-03-20T22:11:00.000-08:00

Things You Need To Know Before Installing
- Can you run both get and post method cgi programs on your server?This is not relevant if you installing the Apache module version. If not, you can not use this package. On many public ISP's CGI programs are either disallowed or severely restricted. If this is the case on your system, talk to your system administrator and ask him/her to have a look at this package and see if they will install it for you.
- If you have mSQL installed on your system, you need to know the base directory of this installation.
- If you have Postgres95 or PostgreSQL installed on your system, you need to know the base directory of this installation.
- If you are going to be storing log and access configuration files in an NFS-mounted directory and your system does not provide NFS file locking then you will need to define the NFS_HACK variable manually in the src/Makefile and you may want to use a slightly modified version of the gdbm library. See the nfs_hack.txt file in the doc directory for more information on this.
- Note that if you are not interested in using PHP to track accesses to your pages, do not compile this option into the binary. You should also leave out the access restriction code. There is considerable overhead in including these options.
- If you are installing the Apache module version, you will need to know the Apache src code directory location.

2006-03-20T22:10:00.000-08:00

Installation Instructions

Before You Begin: If you have absolutely no Unix experience, you may want to ask around for someone with a little bit of Unix knowledge to help you through this installation. Every attempt has been made to make it as simple as possible, but since the software is quite involved and relies on a number of different components, it is not realistic to assume it will go smoothly on all systems. You will probably need someone around who knows the particulars of the destination system well.

2006-03-20T22:00:00.000-08:00

Brief History
PHP began life as a simple little cgi wrapper written in Perl. I wrote it in an afternoon during a period between contracts when I needed a quick tool to get an idea of who was reading my online resume. It was never intended to go beyond my own private use. The web server where I had my resume was extremely overloaded and had constant problems forking processes. I rewrote the Perl wrapper in C to get rid of the considerable overhead of having to fork Perl each time my resume was accessed.
Eventually other people on the same web server came across my wrapper and asked if they could use it. Then, as inevitably happens, they started asking for more features. I added more features and finally put together a semi-complete distribution along with documentation, a mailing-list and a FAQ. The name of this first package was Personal Home Page Tools, which later became Personal Home Page Construction Kit.
At the same time I started playing with databases and wrote a tool to easily embed SQL queries into web pages. It was basically another CGI wrapper that parsed SQL queries and made it easy to create forms and tables based on these queries. This tool was named FI (Form Interpreter).
PHP/FI version 2.0 is a complete rewrite of these two packages combined into a single program. It has now evolved to the point where it is a simple programming language embedded inside HTML files. The original acronym, PHP, has stuck. It isn't really appropriate any longer. PHP/FI is used more for entire web sites today than for small Personal Home Page setups. By whatever name, it eliminates the need for numerous small Perl cgi programs by allowing you to place simple scripts directly in your HTML files. This speeds up the overall performance of your web pages since the overhead of forking Perl several times has been eliminated. It also makes it easier to manage large web sites by placing all components of a web page in a single html file. By including support for various databases, it also makes it trivial to develop database enabled web pages. Many people find the embedded nature much easier to deal with than trying to create separate HTML and CGI files.
PHP Version 3.0 is yet another rewrite. If you are just starting out with PHP, I suggest that you start with Version 3.0 instead of continuing with 2.0 at this point. PHP3 is quickly going to replace PHP/FI 2.0 and all development efforts are now focused on PHP3. Any remaining bugs in PHP/FI 2.0 are unlikely to be fixed unless they are straightforward. More information on PHP3 can be found at http://www.lerdorf.on.ca/php3.
Throughout this documentation any references to PHP, FI or PHP/FI all refer to the same thing. The difference between PHP and FI is only a conceptual one. Both are built from the same source distribution. When I build the package without any access logging or access restriction support, I call my binary FI. When I build with these options, I call it PHP.

2006-03-19T15:37:00.000-08:00

Php merupakan bahasa program yang bagus untuk membuat web situs