Get windows loginID securely for MSAccess (1 Viewer)

Status
Not open for further replies.

pkstormy

Registered User.
Local time
Today, 04:15
Joined
Feb 11, 2008
Messages
64
This is the GetUser example which securely retrieves the windows user loginID to an MSAccess form (or anywhere in an mdb). Here's a list of what this new example does:

1. Simply call the GetUser function to retrieve the windows loginID of the current user using the computer. This example has a very nice Main Menu form which demonstrates how all this can be done. I also added some handy functions and if you look at the modules, you'll notice that the 'Check For Admin' module has the functions which do the security checks and the 'UserName (GetUser)' module is the function which retrieves the windows loginID. The 'FormInfo' and 'SystemInfo' class modules are from the Access Developer's book by Sybex and I import and use these modules in every mdb I develop (see comments in the modules for all the things you can do using them.) The FormInfo is used and called in the GetUser form's OnOpen event to manipulate the form without the form's caption bar.

2. =GetUser() can be used anywhere (i.e. in a report, in a query as an expression, on any form, or in calling another function.) It is a very trusted method which I've used for many, many years now. You should have a field in your data table (called something like: EnteredBy) and then on the form, simply set the default value of the EnteredBy field to =Getuser(). Along with a DateEntered field, this is a great way to track who entered the record and when.

3. This example also shows how you can set up a permissions type system giving users different security levels. This is done via having a 2nd field in the dbo_AdminTable called SecurityLevel (integer field type). Additionally, another relational table could be added describing what the integer values represent. I prefer using this method versus making users always enter their username and password (and it will make your users much happier not having to do this.) I honestly don't know why developers like to make user's enter a username/password when this can so easily be embedded with a secure way to get the loginID.

4. I made this example so you can change and 'simulate' on the form with another user's loginID in the dbo_AdminTable. Notice when you change to another user's login, that buttons on the form become visible/invisible or enabled/disabled depending on their security level (which is called via the function: RetSecLevel in the Check for Admin module.) The loginID is passed to RetSecLevel and it returns the SecurityLevel value from the dbo_AdminTable.

5. I also demonstrate (via the IsAdmin function) how you can just determine if the user is in the dbo_AdminTable versus utilizing a SecurityLevel field. So what you could do is have a separate table as an "admin" type table and use that to determine security by simply checking to see if the loginID exists in the table. In a scenario, you might have an AdminAllowEdits table or an AdminReadOnly table and check for loginID's in those tables (but I prefer and encourage simply using a SecurityLevel type field.)

6. The example also shows how you can make buttons visible/invisible or enabled/disabled depending on the security level of the user in the dbo_AdminTable. When you change to another loginID, you'll notice how the buttons change on the form. In an application, you might show an "Admin Functions" type button if the user's securitylevel value is 5 for example. In this example I made it so the buttons change if the securitylevel is > 3. But try changing the loginID to "JoeSomebody" in this example to see what I mean (note: you'll have to click the "Change to Me" button or to another user with a higher securitylevel if you want to close the form.)

7. This example utilizes a "MainFormBackGround" which is a technique I've often used whereby you can 'disable' the MSAccess Menu items by maximizing the MainFormBackGround form and then making the Main Menu form a Popup/Modal. This is ideal versus making the menu items invisible which you then have to make visible again to do any designing. The MainFormBackGround hides access to the tables, forms, queries, reports, etc.. and the popup/modal form "locks" it so you can't close the MainFormBackground.

8. Hence, in this example, you cannot get behind the scenes unless you have a security level > 0 (so when you click the Close button, the form will close) or you must open the mdb while holding down the shift key.

9. When you first open the mdb, it will detect that your loginID is not in the dbo_AdminTable and it will automatically add your loginID (with a security level of 1 so you can utilize the Close button on the Main Menu form.) This is done via the IsNewUser function in the Check For Admin module and is called when the Main Menu form opens. There's also a button on the Main Menu form to add new users or edit your loginID/Security Level. If you accidently change your loginID's security level to 0, you need to open the mdb with the shift key and edit the dbo_AdminTable (or change to a user with a higher security level.)

10. Use the techniques in this example to put into your application and make your life (and your user's life) much easier when it comes to getting the windows loginID and setting up permissions (also see the example I posted in the code bank on how to get Active Directory logins which also has a security level example.)

I made a 2000 and 2002 mdb version in the zip file. There's absolutely NO hidden secrets, hidden routines, or complicated coding involved or any trial type usage.

Please send me feedback if you find this example useful. You're free to use any part of the code.
 

Attachments

  • PKsGetUserAndSecurityLevelsExample2000.zip
    256.6 KB · Views: 3,982
Status
Not open for further replies.

Users who are viewing this thread

Top Bottom