Chapter 16 Security Authorization Question

Imar · March 1st, 2012, 06:52 PM

Then if the Employee ID is unique, why do you need to store the password?

Imar

vbboyd · March 1st, 2012, 07:18 PM

We are not storing the password we are storing the EmployeeID# which the Employees are using as their password to log onto the system. The database is already set up that way. So when they log on they first log onto the network system and then they log on to the Employee Portal, which they use their names and their EmployeeID# as their passwords. Only do Administrators for each department have read, write, and delete privileges in the Employee Portal. Everybody else has just read privileges. So once they log on and use their EmployeeID#'s as passwords on the Employee Portal, from there I can I find out which department they belong to and if they are department administrators for the Employee Portal or not. The problem is we have to verify them against the Employee Database first to find out which department they belong to and then what are their user privileges and then assign that to session objects which follow them around as they navigate from webpage to webpage. Not the best way to do things, I agree but if you know or suggest a better way to do it, then I am like an Iowa cornfield: I am all ears.

vbboyd · March 1st, 2012, 07:42 PM

The situation is not set up like you do in your book. We don't let the employees log into the Employee Portal and set up their own passwords. Those are already provided and put in the database by the DBA. They just log in and use their Employee Names as a USERID and their EmployeeID's as their password. Then from there, I grab the EmployeeID# and put it in as parameter for a SQL query and that way I can find out which department they belong to and if they are department admins. That information then gets put into a Session object if they are department admins and if they are department admins then only certain web elements are made available to them. So in other words, if they are Admins then I do a if test and see if their session IDs say they are Admins and if they are they can see certain weblinks, buttons, drop down lists ect. Kind of similar to what you do in your book on pages 614 thru 616. I still haven't found out a way to do it differently so that you don't have to create 20 different user roles for 20 different departments other than capturing their Passwords and putting it into a parameter in a query and then finding out what department they belong to and if they are administrators or not.

Imar · March 1st, 2012, 07:50 PM

This is conceptually what I would do too. It makes sense to capture something unique about the user (such as a unique ID or a role / department) and use that to fire customized queries.

It's just that using the password seemed wrong to me. However, you're using the unique ID which you incidentally use as the password as well.....

Imar