I do have a question, and I am sure this forum will give me some great feedback!
I am developing a small app where I have 2 different kind of users (logged in users to be exact!); backend users and frontend users.
I am thinking about creating 2 different tables in the database, where the backend users are in the “Users” table, and the frontend users are in the “Customers” table! I do think this is a good idea since I then can’t mix those very different roles together… Also the gui and actions will be completly differet for the 2 different kind of users! Some of the data will be the same, but the actions and layout will be completly different!
Should I implement my Authentification like this, and create 2 instances of the CUserIdentity implementation?
Or should I go for the regular role based authentification?
And to add; I see this more as 2 different applications (Frontend application and Backend application), more than 2 different views of the same application!
Module should give you the answer. Just add a backend module to your (frontend) site.
I suppose they have different roles you don’t want to group in a single user table. This way, any user will have access to the backend login page.
With single user table and login form, you could display a 404 when someone try to reach the backend homepage without backend rights.
For that you need user, frontend_roles and backend_roles tables and any user can be customer, admin or both. Only you know the answer.
Back to your post title: assuming they both use username & password for login, you will have to extend CUserIdentity twice, at least for CUserIdentity->setState(). Or, i never had to try this, call your unique CUserIdentity class from the backend module if it’s possible…and manage the users/customers (tableName, setState) in authenticate().
I see that this design is a matter of preferences, but I still like the fact that the 2 different kind of users (they might also have their own roles internally) as 2 different tables with 2 different CUserIdentity implementation. Aldo, I do not want the front end user to become a back end user by a mistake, so I really want to separate them as good as possible!
But with this implementation it will be harder to maintain the db and the sctipt, but I do think it is worth it.
Another, possibly more generic, solution is to have just 1 userIdentity class. Override __construct and add an extra parameter: $userIdentity = new UserIdentity($username,password,$frontEnd). Within construct store this $frontEnd in a class property and then call parent::__construct($username,$password).
For your login you have to implement the UserIdentity::authenticate() method. In this method check the $frontEnd property and based on its value you authenticate using the front-end or back-end user table.
Or you could just make 2 methods in UserIdentity: authenticateFrontEnd() and authenticateBackEnd() and call the appropriate authenticator.
