views:

120

answers:

5

I'm going to make a small application for a business that will be used locally for scanning, and storing documents in a database located on the local machine or on a machine located in the same LAN.

I could create a table called Users with username and password and according to the usertype ID show a form, or another form. But I'm more interested in the recommended approach by seasoned programmers.

Any advice?

Edit: I'm looking for something that will be secure enough, but also extensible enough.

A: 

I could create a table called Users with username and password and according to the usertype ID show a form, or another form.

Sounds like a reasonable way to go to me. Just remember to hash the passwords.

I would also componentize the common controls in the forms, so you can reuse the common parts.

Kevin
A: 

If you are using Visual Studio, I would just use the built in Membership providers. That would take care of your database and everything automatically. No need to reinvent the wheel.

hmcclungiii
Using ASP.Net providers in WinForms is not secure: http://stackoverflow.com/questions/1002645/is-using-the-asp-net-membership-providers-in-winforms-application-a-bad-idea/1002714#1002714.
Groo
@Groo: The same argument can be made against any system that handles the data locally, though you could fudge around this by running it over a LAN. You can easily enough use ACL to avoid giving users permissions to actually replace any of the executable stuff, but really if your users are both skilled enough to do this and motivated enough to break through, you're still pretty much doomed with most local solutions.
Brian
A small application used locally for a small business doesn't sound like they are in need of Fort Knox security ;)
hmcclungiii
+1  A: 

Even I cannot consider myself "seasoned", I would give my answer since I'm facing the same problem in these weeks.

I would define a permission mask in order to identify allowed operations, associate it to role groups, and then associate users to the groups. More complete is the permission mask, more granularity is allowed in the group definition.

In this way there is one permission definition for multiple users, which is better than define the role using a per-user type basis, since the permission mask can be modified and extended.

More complex schemes could be possible, which could allow per-user permission overriding group permission, or hierarchy permission masks in order to define supervisor users able to manage group permissions. The application of these models depends by the required scalability and by the number of users of the system.

Luca
A: 

Although orientated towards ASP.NET, I'd thoroughly recommend checking out this article: http://www.4guysfromrolla.com/articles/120705-1.aspx

You can use the in-built Membership and Roles objects (even in a desktop application) to define your own schemas of privilege. Using this feature takes the hassle out of creating your own database entries for the Users (and Roles) tables, while also handling password hashing for you (leading to more secure applications).

Lastly, official MSDN articles you might want to read:

On "Membership": http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx

On "Roles": http://msdn.microsoft.com/en-us/library/ff647401.aspx

Martin Eve
A: 

If it's just a simple application, don't use a spaceship to cross the road.

Create the following DB schema:

Users : username and hashed password

Roles : RoleName, RoleID, RoleStrength(int)

RolesMembership : Rolemembership table that contains userid and roleid to allow for future multiple membership.

When setting up roles, give them a numeric weight. ie: Admins = 1000, Power-users = 500, guests = 10. This way, on your forms, you can say, if user level is 500 or above, set full view, otherwise, view only or no access.

Better yet, abstract it out with a security class with methods like IsPowerUser, or IsAdmin.

It's simple, readable and reusable.

asp316