Results 1 to 6 of 6
  1. #1
    Join Date
    Sep 2006
    Posts
    2

    Unanswered: Creating a login form page for a database

    I have been trying numerous routes but still can't figure out a basic way to set up a simple login page for the database.

    I have a table (tblEmlployees) with 2 fields (txtPAssword and txtUserName)

    I have begun to create a form with two unbound fields for the user to type in their ID and Password, but I'm running into issues with how to write the Event Procedure to validate the ID and Password.

    Does anyone have this basic code? I've been searching through the threads and haven't found anything yet.

    Any help you could provide would be amazing!

    Thanks,
    Rich
    rnbcarter@comcast.net

  2. #2
    Join Date
    Mar 2003
    Location
    The Bottom of The Barrel
    Posts
    6,102
    Provided Answers: 1
    How secure are you trying to make this? Is there encryption involved?

    Real basic might be:

    If DCount("user", "tblUser", "password = '" & txtPassword & "' AND user = '" & txtUser & "'") > 0 Then
    'passed
    Else
    'failed
    End If


    It's generally frowned upon to store credentials in clear text though, fair warning.
    oh yeah... documentation... I have heard of that.

    *** What Do You Want In The MS Access Forum? ***

  3. #3
    Join Date
    Dec 2004
    Location
    Madison, WI
    Posts
    3,926

    login

    Under the MSAccess forum, I have a couple of posts on how to easily retrieve the user LoginID (I attached it here.). You could easily set up a table with 2 fields, LoginID and Password. This would save the user having to always enter their LoginID (which would become a pain for them).

    What I actually do is have several tables of permissions with a LoginID field for specific permissions on what the user can do. If the LoginID is in the AdminMaintenance table, they can edit the Maintenance menu, If their loginID is in the AdminLookup table, they can edit lookup items, etc.. I think the example in the attachment shows you how you can do something like this (look at the function isadmin() under the Check For Admin Module - the form also gets you started). You could have several "admin" type tables and other functions like isadminlookup, isadminmaintenance, isadmindelete, etc...or get even fancier and have a table which has the loginID and the type admin service and some basic/fancy modifications to the code where you call a certain function depending on what the user is trying to do and if it's listed in the type admin service table...it can probably get even fancier but you have the option of doing it several different ways. I've used this technique quite a few times and it's worked out pretty well for me. Others on this site though might have some different suggestions they've done in regards to security and so on.

    Personally, I dislike a program where you have to put in your username and password each time to get into the program and then also to get into certain forms (they've already logged into Windows and if you don't want them to use this program, just do a comparison of the loginID with the admin table(s) in the onopen event of the MainFormBackground.) Either that or assign permissions at the file/mdb level.

    One last note: You'll notice that I have a modal form (modal type under the properties) (getuser - don't confuse the form name with the function getuser()) and a MainFormBackGround form. You must close the modal (getuser) form first and then close the MainFormBackground where you would add your login to the dbo_adminTable table. Utilizing a pop-up modal form with a Background form (that is maximized) is a nice way of keep users from using the upper menu system and gives you certain control over who can get "Behind the scenes" to see the tables. The onload code takes care of the right-click to design mode on the form. Most users aren't familiar with the shift key to bypass code and most also won't know some of the other tricks to get behind the scenes but if you wanted to, you could protect your app even further. This is just a quick, down and dirty, easy way of doing it and I'm not sure if it has any minor holes or not. Having an Admin close type of button on the Main Form where I close all the forms including the background form if it sees certain loginIDs or my loginID helps out a lot.

    You also need to include the other class modules for the getuser function to work. You'll notice there are some other neat things you can do on objects from looking through the class modules.

    And another last note: You can utilize the =getuser() function almost ANYWHERE, including a field on the form maybe called: EnteredBy where the default value is =getuser() (in conjunction with a DateEntered field which defaults to =date() - or in a query to see who entered what or as an expression, etc, etc... --- EnteredBy and DateEntered are what I would call some standard fields to have in your most important tables of information or anything you'd want to track entries on.

    I'm sure you'll get some different suggestions on how you want to do it.
    Attached Files GetUserAndPermissionsSample.zip (516.5 KB, 1 views)

    __________________
    Attached Files Attached Files
    Last edited by pkstormy; 09-05-06 at 23:29.
    Expert Database Programming
    MSAccess since 1.0, SQL Server since 6.5, Visual Basic (5.0, 6.0)

  4. #4
    Join Date
    Sep 2006
    Posts
    2

    Talking thanks! I'll give it a shot...

    PK - Thanks!!!!!
    This should definitely get me going here.

    Thanks a bunch!!!!!!!!!!

  5. #5
    Join Date
    Jun 2012
    Posts
    1
    thanks, looking a long time for this

  6. #6
    Join Date
    Nov 2011
    Posts
    11
    Quote Originally Posted by pkstormy View Post
    Under the MSAccess forum, I have a couple of posts on how to easily retrieve the user LoginID (I attached it here.). You could easily set up a table with 2 fields, LoginID and Password. This would save the user having to always enter their LoginID (which would become a pain for them).

    What I actually do is have several tables of permissions with a LoginID field for specific permissions on what the user can do. If the LoginID is in the AdminMaintenance table, they can edit the Maintenance menu, If their loginID is in the AdminLookup table, they can edit lookup items, etc.. I think the example in the attachment shows you how you can do something like this (look at the function isadmin() under the Check For Admin Module - the form also gets you started). You could have several "admin" type tables and other functions like isadminlookup, isadminmaintenance, isadmindelete, etc...or get even fancier and have a table which has the loginID and the type admin service and some basic/fancy modifications to the code where you call a certain function depending on what the user is trying to do and if it's listed in the type admin service table...it can probably get even fancier but you have the option of doing it several different ways. I've used this technique quite a few times and it's worked out pretty well for me. Others on this site though might have some different suggestions they've done in regards to security and so on.

    Personally, I dislike a program where you have to put in your username and password each time to get into the program and then also to get into certain forms (they've already logged into Windows and if you don't want them to use this program, just do a comparison of the loginID with the admin table(s) in the onopen event of the MainFormBackground.) Either that or assign permissions at the file/mdb level.

    One last note: You'll notice that I have a modal form (modal type under the properties) (getuser - don't confuse the form name with the function getuser()) and a MainFormBackGround form. You must close the modal (getuser) form first and then close the MainFormBackground where you would add your login to the dbo_adminTable table. Utilizing a pop-up modal form with a Background form (that is maximized) is a nice way of keep users from using the upper menu system and gives you certain control over who can get "Behind the scenes" to see the tables. The onload code takes care of the right-click to design mode on the form. Most users aren't familiar with the shift key to bypass code and most also won't know some of the other tricks to get behind the scenes but if you wanted to, you could protect your app even further. This is just a quick, down and dirty, easy way of doing it and I'm not sure if it has any minor holes or not. Having an Admin close type of button on the Main Form where I close all the forms including the background form if it sees certain loginIDs or my loginID helps out a lot.

    You also need to include the other class modules for the getuser function to work. You'll notice there are some other neat things you can do on objects from looking through the class modules.

    And another last note: You can utilize the =getuser() function almost ANYWHERE, including a field on the form maybe called: EnteredBy where the default value is =getuser() (in conjunction with a DateEntered field which defaults to =date() - or in a query to see who entered what or as an expression, etc, etc... --- EnteredBy and DateEntered are what I would call some standard fields to have in your most important tables of information or anything you'd want to track entries on.

    I'm sure you'll get some different suggestions on how you want to do it.
    Attached Files GetUserAndPermissionsSample.zip (516.5 KB, 1 views)

    __________________
    pkstormy wouldent He also be better off with verifying LDAP roles? He then would only need a table with say the role group and the permission level allowed? That way he would not need to specify each user he would only need the role group(or functional Role group) as they got added to the rol group it would roll to the DB. Just a thought. I have the code to do that if it is needed or suggested.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •