Passwords To Identify Users And Populate date/timestamp

[Mary Bowman via AccessMonster.com]

I have six Users that will update the table. I have a password pop-up box
to enter a password in order to open the form and edit records. How do I
give (6) separate passwords to each User and then auto populate the form
with the user name, date and timestamp while they edit each record.

Below is my password code, but how do I from the password, identify the
User and then populate the record with the name and timestamps?


Dim F As Form
Set F = Forms![frmPswrdEdit]

If F!pwd = "awesome" Then GoTo pwd_success

If F!pwd <> "awesome" Then GoTo pwd_invalid
If IsNull(F!pwd) Then GoTo pwd_invalid
If Len(F!pwd) = 0 Then GoTo pwd_invalid

On Error GoTo pwd_trap

pwd_success:
DoCmd.Close acForm, "frmpswrdEdit"
DoComd.Open “frmClientUpdate”
Exit Sub

End Sub

Thanks,
Mary Bowman

 

[Rick B]

Why are you reinventing the wheel? Why do you want a user to have to enter
a password EVERY time they open a particular form? What prevents them from
simply opening the table and making changes (bypassing all your work)? What
prevents them from simply reading your code and thus seeing the password?
Using your current approach is no more certain than simply asking the user
to select their name from a drop-down box any time they change a record.

You should implement User-Level security which comes with Access. Then,
each user will enter a userid and password one time when they open the
application. All security access will be set at that time. You will have
the CurrentUser() variable available to you to get the current user's
userid. This can be used in code, or in field definitions.

I'd recommend getting rid of all your home grown security and using the
built in features. The following links will point you in the right
direction. I would make a backup or two before putting these changes in
place. I'd also read and reread the following links before starting. You
must follow EVERY step and you must do them IN ORDER.

Good Luck,
--
Rick B

Security FAQ

http://support.microsoft.com/?id=207793



The Security Whitepaper is also worth reading to help you understand.

http://support.microsoft.com/?id=148555



Joan Wild:

www.jmwild.com/AccessSecurity.htm



Lynn Trapp

http://www.ltcomputerdesigns.com/Security.htm

 

[Klatuu]

Mary,

Here is how I have done it.
I have a table in my back end that contains User Id and Password fields. I
have an encryption routine that makes them unreadable.
When a user logins in, I encrypt his/her id and password and look to see if
the user is in the database and if the password is good.
If it is a valid user, I create two application level properties. UserID and
UserPassword and assign the values to the properties.
Then when you need the values (not encrypted, by the way) you can reference
the properties.

 

[Klatuu]

Rick,

I have seen you post almost the identical verbage before. I agree that
security should be applied when opening the application. I think it is fine
to reinvent the wheel when the existing wheel is low on air and wobbles.
Perhaps you are much more experienced with Acces security than I, but after a
lot of frustration with it, I invented my own wheel. So far it has been
rolling along quite well. I have been considering trying it again, hoping
things improve over time. Maybe you would have some pointers for me.

1. If I use Access security, are there objects or properties I can use to
know who the user is for things like audit updates?
2. Where is the best place to put the MDW file when everyone has their own
copy of the fe mde and the be is on the Server?
3. If I apply user and group security to the fe, how is the be protected?

With your assistance, I will do some experimenting, because I do buy into
your concept of not reinventing.

Thanks

Why are you reinventing the wheel? Why do you want a user to have to enter
a password EVERY time they open a particular form? What prevents them from
simply opening the table and making changes (bypassing all your work)? What
prevents them from simply reading your code and thus seeing the password?
Using your current approach is no more certain than simply asking the user
to select their name from a drop-down box any time they change a record.

You should implement User-Level security which comes with Access. Then,
each user will enter a userid and password one time when they open the
application. All security access will be set at that time. You will have
the CurrentUser() variable available to you to get the current user's
userid. This can be used in code, or in field definitions.

I'd recommend getting rid of all your home grown security and using the
built in features. The following links will point you in the right
direction. I would make a backup or two before putting these changes in
place. I'd also read and reread the following links before starting. You
must follow EVERY step and you must do them IN ORDER.

Good Luck,
--
Rick B

Security FAQ

http://support.microsoft.com/?id=207793



The Security Whitepaper is also worth reading to help you understand.

http://support.microsoft.com/?id=148555



Joan Wild:

www.jmwild.com/AccessSecurity.htm



Lynn Trapp

http://www.ltcomputerdesigns.com/Security.htm

I have six Users that will update the table. I have a password pop-up box
to enter a password in order to open the form and edit records. How do I
give (6) separate passwords to each User and then auto populate the form
with the user name, date and timestamp while they edit each record.

Below is my password code, but how do I from the password, identify the
User and then populate the record with the name and timestamps?


Dim F As Form
Set F = Forms![frmPswrdEdit]

If F!pwd = "awesome" Then GoTo pwd_success

If F!pwd <> "awesome" Then GoTo pwd_invalid
If IsNull(F!pwd) Then GoTo pwd_invalid
If Len(F!pwd) = 0 Then GoTo pwd_invalid

On Error GoTo pwd_trap

pwd_success:
DoCmd.Close acForm, "frmpswrdEdit"
DoComd.Open "frmClientUpdate"
Exit Sub

End Sub

Thanks,
Mary Bowman

 

[Rick B]

I have not had to implement security from scratch in a while. I mostly work
with a handful of existing databases.

I'm not sure what item 1 means. If you are asking how you can update a
timestamp field, you can use the CurrentUser() to have the current userid
inserted into a field.

2. I have my MDW file in the same folder as my backend.

3. In short, the back-end protection is an issue. I have seen posts in the
past that tell you to hide it deep within folders so it is hard for the user
to locate them. I think you could also take away access to the various
tables and use "run with owner permission" queries to update the tables. In
my case, my users are smart enough to open a table directly from the
front-end and bypass my forms (if I did not secure against this) but they
are not smart enough to understand what the back-end is all about. None of
them understand that the data they are changing actually lives back there.

I have looked over several previous posts (mostly from Joan Wild) and she
seems to agree that accessing the back end using RWOP queries is the only
way to prevent access to the back-end tables. She also mentions hiding the
file to reduce the likelyhood of someone getting to it.


Our company writes software, and we have some compititors that use the
"enter a password to open this form" or "enter a password to perform this
function" scenarios. We think it is clunky and insist on setting all
security when the user logs on. I am just a firm believer in following that
same methodology in my databases.

Good Luck.

--
Rick B

Rick,

I have seen you post almost the identical verbage before. I agree that
security should be applied when opening the application. I think it is fine
to reinvent the wheel when the existing wheel is low on air and wobbles.
Perhaps you are much more experienced with Acces security than I, but after a
lot of frustration with it, I invented my own wheel. So far it has been
rolling along quite well. I have been considering trying it again, hoping
things improve over time. Maybe you would have some pointers for me.

1. If I use Access security, are there objects or properties I can use to
know who the user is for things like audit updates?
2. Where is the best place to put the MDW file when everyone has their own
copy of the fe mde and the be is on the Server?
3. If I apply user and group security to the fe, how is the be protected?

With your assistance, I will do some experimenting, because I do buy into
your concept of not reinventing.

Thanks

Why are you reinventing the wheel? Why do you want a user to have to enter
a password EVERY time they open a particular form? What prevents them from
simply opening the table and making changes (bypassing all your work)? What
prevents them from simply reading your code and thus seeing the password?
Using your current approach is no more certain than simply asking the user
to select their name from a drop-down box any time they change a record.

You should implement User-Level security which comes with Access. Then,
each user will enter a userid and password one time when they open the
application. All security access will be set at that time. You will have
the CurrentUser() variable available to you to get the current user's
userid. This can be used in code, or in field definitions.

I'd recommend getting rid of all your home grown security and using the
built in features. The following links will point you in the right
direction. I would make a backup or two before putting these changes in
place. I'd also read and reread the following links before starting. You
must follow EVERY step and you must do them IN ORDER.

Good Luck,
--
Rick B

Security FAQ

http://support.microsoft.com/?id=207793



The Security Whitepaper is also worth reading to help you understand.

http://support.microsoft.com/?id=148555



Joan Wild:

www.jmwild.com/AccessSecurity.htm



Lynn Trapp

http://www.ltcomputerdesigns.com/Security.htm






in message news:[email protected]...

I have six Users that will update the table. I have a password pop-up box
to enter a password in order to open the form and edit records. How do I
give (6) separate passwords to each User and then auto populate the form
with the user name, date and timestamp while they edit each record.

Below is my password code, but how do I from the password, identify the
User and then populate the record with the name and timestamps?


Dim F As Form
Set F = Forms![frmPswrdEdit]

If F!pwd = "awesome" Then GoTo pwd_success

If F!pwd <> "awesome" Then GoTo pwd_invalid
If IsNull(F!pwd) Then GoTo pwd_invalid
If Len(F!pwd) = 0 Then GoTo pwd_invalid

On Error GoTo pwd_trap

pwd_success:
DoCmd.Close acForm, "frmpswrdEdit"
DoComd.Open "frmClientUpdate"
Exit Sub

End Sub

Thanks,
Mary Bowman

 

[Klatuu]

Thanks, Rick. I think I need to do some experimenting. I agree that one
login should do anything you are allowed to do. It is just that I have seen
people having a lot of problems trying to get it implemented correctly. What
I have been doing for the back end is putting in a startup that does nothing
but a docmd.quit. Of course, if a user knows about the Shift key, they can
get around that. Usually they do not. My problem is that all my users are
in IT, so it will take something pretty tricky to keep them out.

I always distribute mde's to limit what a user can do. It is almost
impossible for them to do anything that is not in my App. If they try to
close the main form, it quits the app.

I have not had to implement security from scratch in a while. I mostly work
with a handful of existing databases.

I'm not sure what item 1 means. If you are asking how you can update a
timestamp field, you can use the CurrentUser() to have the current userid
inserted into a field.

2. I have my MDW file in the same folder as my backend.

3. In short, the back-end protection is an issue. I have seen posts in the
past that tell you to hide it deep within folders so it is hard for the user
to locate them. I think you could also take away access to the various
tables and use "run with owner permission" queries to update the tables. In
my case, my users are smart enough to open a table directly from the
front-end and bypass my forms (if I did not secure against this) but they
are not smart enough to understand what the back-end is all about. None of
them understand that the data they are changing actually lives back there.

I have looked over several previous posts (mostly from Joan Wild) and she
seems to agree that accessing the back end using RWOP queries is the only
way to prevent access to the back-end tables. She also mentions hiding the
file to reduce the likelyhood of someone getting to it.


Our company writes software, and we have some compititors that use the
"enter a password to open this form" or "enter a password to perform this
function" scenarios. We think it is clunky and insist on setting all
security when the user logs on. I am just a firm believer in following that
same methodology in my databases.

Good Luck.

--
Rick B

Rick,

I have seen you post almost the identical verbage before. I agree that
security should be applied when opening the application. I think it is fine
to reinvent the wheel when the existing wheel is low on air and wobbles.
Perhaps you are much more experienced with Acces security than I, but after a
lot of frustration with it, I invented my own wheel. So far it has been
rolling along quite well. I have been considering trying it again, hoping
things improve over time. Maybe you would have some pointers for me.

1. If I use Access security, are there objects or properties I can use to
know who the user is for things like audit updates?
2. Where is the best place to put the MDW file when everyone has their own
copy of the fe mde and the be is on the Server?
3. If I apply user and group security to the fe, how is the be protected?

With your assistance, I will do some experimenting, because I do buy into
your concept of not reinventing.

Thanks

Why are you reinventing the wheel? Why do you want a user to have to enter
a password EVERY time they open a particular form? What prevents them from
simply opening the table and making changes (bypassing all your work)? What
prevents them from simply reading your code and thus seeing the password?
Using your current approach is no more certain than simply asking the user
to select their name from a drop-down box any time they change a record.

You should implement User-Level security which comes with Access. Then,
each user will enter a userid and password one time when they open the
application. All security access will be set at that time. You will have
the CurrentUser() variable available to you to get the current user's
userid. This can be used in code, or in field definitions.

I'd recommend getting rid of all your home grown security and using the
built in features. The following links will point you in the right
direction. I would make a backup or two before putting these changes in
place. I'd also read and reread the following links before starting. You
must follow EVERY step and you must do them IN ORDER.

Good Luck,
--
Rick B

Security FAQ

http://support.microsoft.com/?id=207793



The Security Whitepaper is also worth reading to help you understand.

http://support.microsoft.com/?id=148555



Joan Wild:

www.jmwild.com/AccessSecurity.htm



Lynn Trapp

http://www.ltcomputerdesigns.com/Security.htm






in message I have six Users that will update the table. I have a password pop-up box
to enter a password in order to open the form and edit records. How do I
give (6) separate passwords to each User and then auto populate the form
with the user name, date and timestamp while they edit each record.

Below is my password code, but how do I from the password, identify the
User and then populate the record with the name and timestamps?


Dim F As Form
Set F = Forms![frmPswrdEdit]

If F!pwd = "awesome" Then GoTo pwd_success

If F!pwd <> "awesome" Then GoTo pwd_invalid
If IsNull(F!pwd) Then GoTo pwd_invalid
If Len(F!pwd) = 0 Then GoTo pwd_invalid

On Error GoTo pwd_trap

pwd_success:
DoCmd.Close acForm, "frmpswrdEdit"
DoComd.Open "frmClientUpdate"
Exit Sub

End Sub

Thanks,
Mary Bowman

 

[Jeff Conrad]

in message:

Thanks, Rick. I think I need to do some experimenting. I agree that one
login should do anything you are allowed to do. It is just that I have seen
people having a lot of problems trying to get it implemented correctly.

Implementing Access User Level Security (ULS) *IS* a complicated process
until you get the hang of it. Diligent study of the topic from various sources
and practicing on dummy databases until you "got it down" is really the
best advice. Once you understand ULS it becomes a very valuable tool
in your arsenal. You have more control over the application and what
people can and cannot do.

Quite often people just jump into the subject without study by using the
Security Wizard. Although the wizard is a very useful tool, it takes away
the *knowledge* out of the equation. When something does not quite work
properly (and most often something will) then the user is left with, "Now
what did I just do?" And more importantly, "How do I fix this?!"

Even worse off some people just jump into the Security menus and screens
and start "playing" with things, not even realizing they are messing up their
default system workgroup file! I think it would be great if Access could
automatically detect if you are modifying the system.mdw and just pop
up a warning message box saying something like:

"You are about to modify the system workgroup file. This will affect
all databases you use on this machine. Are you sure you wish to proceed
with these changes?"

Also, the first screen of the Security Wizard should present a form that
has links to the Microsoft security information articles and some text about
*suggesting* reading up on the subject if you are a first time security user.

Just my 2 cents.

What I have been doing for the back end is putting in a startup that does nothing
but a docmd.quit. Of course, if a user knows about the Shift key, they can
get around that. Usually they do not. My problem is that all my users are
in IT, so it will take something pretty tricky to keep them out.

I always distribute mde's to limit what a user can do. It is almost
impossible for them to do anything that is not in my App. If they try to
close the main form, it quits the app.

I fall somewhat on the fence on this issue. I believe that one should first
analyze *what* they are trying to protect and from *whom.* I have used
all three types of security and each worked just fine for the project
requirements.

- Database-level password
I used this for an app that had no sensitive data AND the users were very
low tech. This was MORE than adequate to keep lurkers out.

- Home-grown security system.
I have in the past created a login-type system with user information stored
in a table. I further protected the passwords by incorporating some KB
article techniques. The app needed just a little more control over who
can do what. I assigned users to various groups and everything worked
just fine. The users were a bit more sophisticated and might play around
with things they should not be so I controlled where they could go with code.

Was I re-inventing the wheel? Perhaps, but at the time I had not begun to
use ULS. I had glanced at various technical articles and saw that it was a
VERY complex task so I decided to put it off for future study. Was it a
waste of time to make something myself? I do not believe so. I learned
a lot of new coding techniques so I came away from it with new-found
knowledge. What better way to understand how the "wheel" works than
to take it apart? Any time you learn something new I believe time is not
wasted.

-User Level Security
I needed to implement full ULS with all the bells and whistles for a personal
complex application that required really tight control over where and what
users can have access to. It took quite a while to really understand how
the whole process works, but it was needed.

Now understanding how ULS works, I can actually set up some type
of security on a database much faster with ULS than by making something
myself. That, however, comes from the experience and knowledge.

I would recommend ALL of the following reading material before
jumping into ULS if you want to pursue this topic:

http://www.ltcomputerdesigns.com/JCReferences.html#Security

Do not expect to master the subject in an hour, give yourself time.
It can fulfill all your security needs, but many steps need to be
taken before that can happen. Just remember too that ULS has
its own limitations.

Good luck,

 

[Klatuu]

Thanks, Jeff, I will go through it and see what I can do. I see you are in
Bend. I am back in Texas now, but I lived in Aloha and Salem for about 10
yrs. Used to go to Bend occasionally to go the the shooting range about 20
mi east of Bend. Nice town.

 

[Jeff Conrad]

in message:

Thanks, Jeff, I will go through it and see what I can do.

You'll be fine, just take your time with it.

I see you are in Bend. I am back in Texas now, but I lived in Aloha
and Salem for about 10 yrs.

Ohh cool. I lived in the Salem area myself for a while.

Used to go to Bend occasionally to go to
the shooting range about 20 mi east of Bend.

Well that would explain all the holes in my car then.
;-)

Nice town.

Yep, very nice.

 

[Lynn Trapp]

1. If I use Access security, are there objects or properties I can use to

know who the user is for things like audit updates?

Yes, the CurrentUser() function can be used for that. Also, Section 22 of
the Security FAQ shows you how to determine what group(s) a given user is
in, if you want to use that information too.

2. Where is the best place to put the MDW file when everyone has their
own
copy of the fe mde and the be is on the Server?

Put it on the Server

3. If I apply user and group security to the fe, how is the be protected?

Secure the be using the same .mdw file that you use to secure the fe.

--
Lynn Trapp
MS Access MVP
www.ltcomputerdesigns.com
Access Security: www.ltcomputerdesigns.com/Security.htm
Jeff Conrad's Big List: www.ltcomputerdesigns.com/JCReferences.html

 

[Mary Bowman via AccessMonster.com]

Thank you. I've taken everything into consideration. My Users are low
tech. I will use your suggestion.

Thanks again!!

Mary