An aside, if you're using sessions, you're already using cookies; the connection to the current user is kept alive via the PHPSESSID cookie *or* the query string if cookies are disabled. you will indeed need one or the other to maintain a logged in state.
This involves using the username and password data in the database to password protect the pages in the member folder.
Two things stand out here. First is member folder; to protect a directory you're going to have to have
basic authentication [httpd.apache.org] (Apache, different for windows based servers) via an .htaccess/.htpasswd combination, which means as members sign up you are going to have to write the .htpasswd file. Otherwise they can bookmark the page and/or send it to anyone they like, circumnavigating your validation.
The two alternatives are:
- Redirect, via mod_rewrite, any requests to the protected directory to your authentication script, which would open the protected files and print them out to the browser. No authentication, print out a login form and exit. A simple redirect won't do, it can be bookmarked and saved, you need to pass the request through your login script to authenticate the user and actually read in the file, print it out to the browser.
- A more sensible approach, which is the second thing, is that since you already have a database, just store the protected content in the database and use the method above. If authenticated, extract the "pages" dynamically from the database and output them to the browser. This will make life a lot easier in the long run, in backing up, templating, and applying any global changes to your protected pages.
