I am not asking for code but rather design ideas. I am trying to develop a new system to learn more about client/server development.
I would have 3 systems:
Client 1 : Client
Server 1 : Server
DB Server 1: DB Server
I would develop a server application as well as a client application
What happens is that my idea would be to use DB authentication where the clients actually have different access rights which are stored in a DB table on the DB server.
However, different access rights would get access to different features in the application. For example, a superuser would log in with his account by sending data from the client to the Server application running on Server 1, which would then check the superuser table in the DB to check if the account exists.
My initial idea would be to send the account object back to the client in which the client application would check what type of account it belongs to and actually displays the corresponding form/User Interface to the user.
However, this approach does not seem very feasible as it seems too flimsy and incorporates a lot of bad design.
Perhaps someone could give me a better idea on how do i approach this problem.
Summary : It would be just like a client server application but there would be different kinds of users being allowed different rights and different features.
5
Your initial idea seems OK to me. One way or another, the client needs to respond to the role membership, and sending back information about the role membership is one solution to the problem. In fact it probably is a simple and effective one.
Another approach would be to implement some inversion of control patterns and simply let the server instruct the client what needs to be displayed as a matter of course. Under this model, the client doesn’t know anything about the details of the UI in the first place, and always just displays whatever GUI the server instructs it to. The changes in the GUI could be on the basis of role membership, then, or any other situation the server detects (say, global policy changes, service status, etc.) This is more complicated, however, and may not be right for your situation.
Either way, though, one thing is very important: always make sure that the access check is performed on the server even if it has theoretically already been checked on the client. Do not simply trust input or actions from the client because you assume such checks were already validly and correctly performed– they could be spoofed by malicious actors or simply reflect out-of-date permissions information. This applies to either model.