Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

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.

share|improve this question

migrated from Aug 22 '13 at 11:16

This question came from our site for professional and enthusiast programmers.

Have a look at something like ASP.NET MVC, roles and membership. This should get you started. –  Adrian Thompson Phillips Aug 22 '13 at 11:24
"this approach does not seem very feasible as it seems too flimsy and incorporates a lot of bad design." Why? You can design this badly, of course, but you can also design this very well - its your choice. –  Doc Brown Aug 22 '13 at 12:27
I would think about what you need the server to do, if it's nothing to complex you could likely remove the 'server' node and just have the client and DB code. –  bendataclear Aug 22 '13 at 14:56
@DocBrown: Designing authentication systems is hard, and you don't find out that you've done it wrong until years later when your site is hacked. Much better to use an existing framework built by experts. In the case of .net, the membership framework is the obvious choice, as Adrian recommends. –  Brian Aug 22 '13 at 17:29
@Brian: to my understanding the question was not how to design an authentification system, the question was how to change access on the GUI level dependent on the result of an authentification / role membership. –  Doc Brown Aug 22 '13 at 18:56

1 Answer 1

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.