I've been working on an example database to demonstrate how to program your own Users and User Groups module. Feel free to download and test this database and then post your feedback here.
This was written for Access 2007 and 2010 but the file format is 2002/2003. You should easily be able to make this work in 2003 by change the two TempVars I've used to be Global variables instead.
There is no error handling anywhere other than the one or two On Error Resume Next statements I used where necessary. This is intentional and I realize that in the real world your database needs error handling.
This does not integrate at all with Active Directory users and groups or your local Windows users and groups.
Also, this is based on the idea that users will login when they start the app and will then the same user will be logged in until he/she closes the application or clicks the log off button. I realize that some people would probably prefer a system where the user enters a user code for every screen. This is not designed with that capability.
Also, there is currently no way to raise your user level to log into one of the administrative screens. The only way to access an administrative level screen is to log out and log back in as a user who has the right permissions.
I did not design any special groups or users. You can delete all of the users and groups if you like and create your own with whatever names you want to use. Do keep in mind that if you choose to do this you will likely end up editing information in the tables because at some point you'll be unable to access any of the forms after you've deleted enough user/group records. You need to have at least one group configured with full rights and one user assigned to this group but I did not write any code to enforce this.
I did employ some basic security techniques but they are not good enough for the real world. Instead of storing the password I'm storing a one-way hash. This hash is generated using a very simple, unsecure hash generator. The one I would have preferred to use cannot be legally distributed in demo applications due to licensing restrictions. I'm also using basic encryption to store the form names. This would make it slightly more difficult for a user who has access to the tables to choose to give himself access to to forms and functions he wouldn't normally have access to. However, any user who has access to the tables could create a real mess by deleting records or clearing certain fields. Access to tables is an entirely different security issue and I've chosen not to tackle that in this example.
This was written for Access 2007 and 2010 but the file format is 2002/2003. You should easily be able to make this work in 2003 by change the two TempVars I've used to be Global variables instead.
There is no error handling anywhere other than the one or two On Error Resume Next statements I used where necessary. This is intentional and I realize that in the real world your database needs error handling.
This does not integrate at all with Active Directory users and groups or your local Windows users and groups.
Also, this is based on the idea that users will login when they start the app and will then the same user will be logged in until he/she closes the application or clicks the log off button. I realize that some people would probably prefer a system where the user enters a user code for every screen. This is not designed with that capability.
Also, there is currently no way to raise your user level to log into one of the administrative screens. The only way to access an administrative level screen is to log out and log back in as a user who has the right permissions.
I did not design any special groups or users. You can delete all of the users and groups if you like and create your own with whatever names you want to use. Do keep in mind that if you choose to do this you will likely end up editing information in the tables because at some point you'll be unable to access any of the forms after you've deleted enough user/group records. You need to have at least one group configured with full rights and one user assigned to this group but I did not write any code to enforce this.
I did employ some basic security techniques but they are not good enough for the real world. Instead of storing the password I'm storing a one-way hash. This hash is generated using a very simple, unsecure hash generator. The one I would have preferred to use cannot be legally distributed in demo applications due to licensing restrictions. I'm also using basic encryption to store the form names. This would make it slightly more difficult for a user who has access to the tables to choose to give himself access to to forms and functions he wouldn't normally have access to. However, any user who has access to the tables could create a real mess by deleting records or clearing certain fields. Access to tables is an entirely different security issue and I've chosen not to tackle that in this example.
