mej!A,
No no, you should be fine. The original issue involved the use of $PHP_AUTH_USER and $PHP_AUTH_PW. These are two special variables which contain the results of an HTTP authentication session. That's when you get that popup window in your browser asking you for a username and password. For details, read the official details at
http://www.php.net/manual/en/features.http-auth.php
and there's a relatively good article by Julie Melonie at
http://www.thickbook.com/extra/wm01redir.phtml
As long as you do not use HTTP authentication as the means by which you obtain the username/password for your users (most sites don't), you have nothing to worry about. For example, this site (PHPbuilder.com), slashdot.org, etc., they all have user logins with customizable pages, and none of them use HTTP authentication.
From the sound of it, you want to do something similar to these sites. As long as you obtain your usernames/passwords via something like basic HTML forms, you're fine. Does that make sense?
As a sidenote, when creating such sites, you normally do not have a separate MySQL database for each user. Rather, you setup one MySQL database to store all the relevant information about your users. For example, you might have
TABLE_USER
| Username | FirstName | LastName | Password |
TABLE_TOPICS
| TopicName |
TABLE_USERPREFS
| Username | TopicName |
This is a single MySQL database with 3 simple tables in it. You then have the username/password you use to connect to the database. This you code into your PHP, as the users will/should never see it. Then you create appropriate webpage forms where users fill in their username/password, and when they submit the form, it goes to a PHP file that takes that form data, opens a connection to the MySQL database, validates the user against the TABLE_USER table, and so on.
For tutorials on all this, there are many excellent examples here on PHPbuilder.com, as well as others on sites like
http://www.php.net/manual/ (the official PHP manual)
http://www.zend.com (see tutorial section, tips section, and others)
http://www.thickbook.com (see tutorial section)
http://www.hotscripts.com/PHP
and a ton of other sites I'm sure I'm overlooking. But to put it plainly, no, you should not have a problem doing user authentication and customized pages running Windows 2000/IIS5 with the PHP CGI version.
ONLY if you use HTTP authentication (which I probably wouldn't recommend anyway) do you have a problem. As I explained, this is authentication done at the webserver level. To give a quick synopsis, when dealing with CGI versions of server-side scripting languages, the scenario is basically:
- Webserver gets request for xxx.php
- Webserver checks its mappings of file extensions and sees that whenever it is asked for .php files, instead of simply returning such a file, the webserver should fire up a separate executable (the PHP engine), feed the .php file to that executable, and then take any output and return that to the browser.
Now note that when HTTP authentication occurs, this authentication process is done directly between the webserver and the web browser. A popup window appears on the browser asking you to type in your username/password. When you do, this information is given to the webserver. Since the PHP CGI engine is a separate executable, it does not "tie in" as it were to the webserver, so it has no way of knowing what was typed in.
The IIS ISAPI module and the Apache module are different. They are not standalone executables. Instead, they are like plugins or puzzle pieces if you will (think extensions if you're a Mac user). These modules "hook into" the webserver, becoming part of its operation as soon as it fires up. As such, it's a little like a Borg mindset. Since the module is hooked into the webserver, it has more access to what the webserver is doing and vice versa.
As for the details of this, you'd better ask the real programmers. But this analogy at the level of server-side scripting, if this makes sense it's all you really need to know. The main difference between CGI versions and modules then is basically this:
CGI versions are like command-line utilities. They are separate programs which often can stand on their own. In fact, the PHP CGI version can be used at a DOS command prompt, and it's quite interesting to see what it outputs. As separate programs, they need to be fired up EACH time a PHP file is requested. That is, each time such a page is requested, it's as if you had to run a program, process some data, print out the answer, then shutdown the application. This means loading the PHP engine into memory, running the program, and then unloading it from memory.
Modules hook into the webserver, becoming part of the webserver in essence. This means the webserver itself is a little bit larger in footprint (uses more RAM, etc.), but since the module is already loaded in memory, any time a PHP file is requested, the file is fed to the module--which is ready to go already--and what you have is far more efficient processing.
That is why, when possible, people run the modules vs. the CGI versions. Unfortunately, the folks at PHP still list the ISAPI module as not being production-level, and they encourage serious users running IIS to stick to the CGI for production level stuff. As such, I too run just the CGI version right now, though my reasons are more due to the session problems in the ISAPI modules (and, for that matter, every version of PHP after 4.0.3pl1). If you plan to use PHP4's session features, I would stick to 4.0.3pl1 for now (though your mileage may vary).
Hope that helps.
