From: Rene Veerman > the "proper way" i know of is not the easiest to implement..; > > 1) create a php script that accepts enough parameters to get at your data. > eg: /products/view.php?dataNr=1&itemNr=1 > 2) let that script compare the current user (visitor who's logged in) > to authentication data that tells which it if the user can access the > data requested. if it fails, you can route the user to a std page or > to a custom page (store in auth-data under "onFail") > 3) use apache's RewriteRule in /products/.htaccess to point virtual > urls to the view script; /products/data1/item_1/data.txt = > /products/view.php?dataNr=1&itemNr=1&file=data.txt (or something like > that). > > the main problem here is how to properly store authentication data. > how far to go depends on your (future) requirements. There are some easier tricks, but still not simple. Only the wrapper script should be in the webroot space. Everything else should be outside of it, but accessible by the user that the web server runs under. The wrapper also manages the session and any other access controls necessary, such as connections to a DB server. Once you parse the parameters from the URL, use require() or require_once() to link in the specific pages you need from outside webroot. This way none of the files or paths are exposed to the browser and nobody can get to those pages without going through the authentication in the wrapper. You can even pull in more than one, so there could be one file for the banner, one for the menu tree on the left column, one for a header, one for the page specific content and one for the footer. It makes global updates relatively easy, but can be a pain to get started. Bob McConnell -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
