password runtime database

premint

Registered User.
Local time
Today, 08:33
Joined
Sep 22, 2017
Messages
16
hello all, not sure if this is the right section but is there a way that i can set a runtime database so that the users can set their own password to protect the database rather than me setting one prior to converting to a runtime product
 
you dont really need to, just use the Windows Login. (let windows control the passwords)
you make a form with text boxes for UserID, Password, Domain
I have a tUser table to store the IDs of those allowed in the system.

1.check if user is in the tUser table
2.check with windows authentication. If they pass both, show the menu, else quit.


Code:
'-------------
Private Sub btnLogin_Click()
'-------------
Dim sUser As String, sPass As String, sDom As String
dim vID, vDbID

sUser = txtUser
sPass = txtPass
sDom = txtDom

vID= Environ("Username")
vDbID = Dlookup("[userId]","tUsers","[UserID]='" & vID & "'"

If WindowsLogin(sUser, sPass, sDom) and vID = vDbID Then
   mbSafe = True
   DoCmd.OpenForm "frmMainMenu"
   DoCmd.OpenForm "frmLogin"
   DoCmd.Close
Else
   MsgBox "LOGIN INCORRECT", vbCritical, "Bad userid or password"
End If
End Sub


'-------------
Public Function WindowsLogin(ByVal strUserName As String, ByVal strpassword As String, ByVal strDomain As '-------------
String) As Boolean
        'Authenticates user and password entered with Active Directory.

        On Error GoTo IncorrectPassword
        
        Dim oADsObject, oADsNamespace As Object
        Dim strADsPath As String
        
        strADsPath = "WinNT://" & strDomain
        Set oADsObject = GetObject(strADsPath)
        Set oADsNamespace = GetObject("WinNT:")
        Set oADsObject = oADsNamespace.OpenDSObject(strADsPath, strDomain & "\" & strUserName, strpassword, 0)
        
        WindowsLogin = True    'ACCESS GRANTED
        
ExitSub:
        Exit Function
        
IncorrectPassword:
        WindowsLogin = False   'ACCESS DENIED
        Resume ExitSub
End Function
 
hi the problem is that i dont know who will be using it, lots of people dont even have passwords on their laptops hence the need for a simple password access
 
hi that looks quite complex for what i need, i can set a simple password by default before i convert to a runtime but then it means whoever i send the database too has to use that one, whereas id rather they could choose one them selves
 
hi that looks quite complex for what i need, i can set a simple password by default before i convert to a runtime but then it means whoever i send the database too has to use that one, whereas id rather they could choose one them selves

So you have a frontend table that holds the password you set when you roll it out. When the database opens, you check to see if it has changed, if not prompt them for a new password and store in table.?
 
sorry im quite new to access and not sure what you mean
 
An Access database for more than one user should be split.. That means each user has their own frontend (form, queries & code) that is on their computer and they all share the backend where the data is.

Most times the tables are in the backend, but if you need a table that is unique to each user you could put it in the frontend.
If it is in the front end I would envisage you only need one record for that user. When your accde is rolled out, that table record has your required password, lets say the password is RollOut

When the frontend opens, you quickly check that record to see if the password is RollOut. if it is, you prompt the user to change the password and save it to the record. Now they will never get asked for it again, however you could give them the option of being to be able to change it when they like, or even make them change it every 90 days or so.

This could all be done from the backend as well, but then as mentioned you would need to keep track of all the users, but the process would be the same except for the fact that the table would hold many records, one for each user.

So if a new user got the database and was not in the table (you should have added them before issuing the database) then it will not run. When you added the user you used the password RollOut as a temporary password. Then on their first run, that process above happens.

It can be as simple as you like or as complicated as you like.

Due to my inexperience I tend to start off with simple and then build on it.
So the frontend scenario would be the easiest to implement, then you could move to the backend scenario as you get more experienced or feel the need.

I often have what I think are good ideas, but have no idea on how I would implement them, and when I do, generally find I need to tweak the data structure to allow for them.

I'm learning all the time.

HTH
 

Users who are viewing this thread

Back
Top Bottom