"Will" <Wi*********@hotmail.com> wrote in
news:34*************@individual.net:
I am looking at using a table with user names, passwords and user
rights, which I would administer. I have read a lot about the
shortfalls of this and the lack of security but the customer does
not wish to use Access security and what they are more focused on
is a solution for when a user performs a critical action the
system can verify that it is actually that user, e.g. Checks User
Name and Password in a table in place of just selecting from a
drop down, (Has anyone implemented similar?). My question is, is
it possible for a user to enter their user name and password when
they open the database and then to store that user name for the
rest of their database activity, rather than requesting that they
put their username and password in on every function?
There's a fundamental flaw in the thinking here. You assume that the
person at the keyboard is the person associated with the
username/password pair that the system is logged in as. You *can't*
assume that.
Say, for instance, that someone logs onto the database with their
personal username/password, and then walks away to have lunch.
Someone else sits down at the computer and pulls up the database and
types all sorts of things into the database. It looks like the lunch
guy did the work, but that's not the case.
You simply cannot know from the internals of Access or any custom
application exactly who is doing the data entry unless you force
them to authenticate for every single operation. Even then, someone
can very easily give someone else their username/password.
If you're going to ask for a username/password, then use Jet
security. It's built-in, it's less crackable than anything you'd
write from scratch and it is stable. You don't have to apply
security to objects, you can use the logon simply to identify the
user (I do this all the time, with no restrictions on security,
often to selectively enable controls and subforms).
I can't think of *any* advantage to rolling your own security for
this purpose.
And even using the NT logonID is going to mean that you have to keep
a table of the usernames somewhere, mapped to their authorization
levels. Why not use the built-in capabilities for doing this?
--
David W. Fenton
http://www.bway.net/~dfenton
dfenton at bway dot net
http://www.bway.net/~dfassoc