Re: Authentication

Addressed to: Frederic Lhoest <frederic.lhoest@afrilink.net> php-general@lists.php.net ** Reply to note from Frederic Lhoest <frederic.lhoest@afrilink.net> Tue, 04 Jul 2000 22:02:07 +0200 > > Thank you for your answer ... > > In fact, here is my goal : > > I want to set up an intranet wich different content for different > users ... for example if user 'Peter' is logged on the intranet will > be personalise for this user ... I mean it will not be the same if > the admin is logged on or the CEO or the President ... you see ? I'd > like to have a dynamic content from the user point of view. > > What is your idea about that ? any suggessions maybe ? I don't see any reason _you_ need to do anything with the password. If Apache is handling the passwords, and your page is hit, they have already given a valid password. You don't have to do _anything_ with the password in your code. The current user name is in $REMOTE_USER, you use that to control your dynamic content. There are two main things you can do based on the user name from $REMOTE_USER: 1. change what they see on menu links. 2. change the fields that they see on the forms that they see, or the data that is available to them on reports. 1 is MUCH easier than 2. Even if you use dynamic links on your menus, you should also make sure the user is authorized to see the page, within each page. You don't want to let someone break into data they should not be able to see just by guessing a URL. I'd be tempted to send back a 404 (?) error, saying the page does not exist, even though it does. I try to avoid messages like "You are not authorized to see that data" in favor of "That page does not exist." The first gives them reason to keep hackin, the second maybe they'll think they got the name wrong on the url they saw on the boss' computer. Definitly plan out what you want different users to see. Ten minutes spent working out who gets what _early_ in the design process might save you ten hours changing something after you start coding. As much as possible have a very small number of different capability levels, and force each user into one of them. The less cases you have to code for the less problems you will have implementing it, and the faster you can verify it works properly. Newer versions of apache let you have more than just username:password in your authentication files, so you could do something like: username:password:real-name:privelege-level:what:ever:else... and keep all the user data in one place. You might allow write permission on the authentication file to the web server, so your administrative users can use a web program to add new users, but watch out! Anyone who can write scripts on your system could update that file. If you have tight control of the server, and who can write scripts, this might be the way to go. Finally, unless you use SSL encryption, remember that the passwords will be flying around your network with every page request. It is quite possible for someone to setup a packet sniffer and steal other people's passwords. Any time I use a password it is SSL encrypted. Rick Widmer Internet Marketing Specialists www.developersdesk.com