Securing a signature field

  • Thread starter Thread starter BruceM
  • Start date Start date
B

BruceM

I am working on a database that is going to be deployed on the network soon.
I will be splitting the database. The front end will be the same for
everybody, as far as I know. Everybody should be able to view it. There is
no confidential information.
As things are now with the Word/paper version of the process, each of the
four sections of the Recommendation is signed upon completion. I would like
to carry this forward to the database, so that after completing, say, the
follow-up, the person who did so can select his or her name from a combo
box, then be prompted for a password. I can do this with a pop-up password
form that is part of the combo box Before Update event, which would be
adequate except that I am also one of the people who will be using the
database, so I should not be able to go in and alter password-protected
information. In other words, I have to keep the passwords secret from
myself.
Maybe I'm on the wrong tack here, but I really don't know how to begin. A
Google groups search produced nothing, perhaps because I was unable to find
a way to phrase the question. I know I can employ user-level security (I
haven't done so on a live database, but I have looked at the instructions
for doing so, and am condfident I could implement it), but I don't see how
that would help with this particular situation.
 
Why not just pop in the "Current User" when the person clicks a "completed"
button?

Don't let them pick a name from a list, let Access enter their name into a
locked field.

Using your "password on a button" solution just has too many holes. What
prevents the user from opening the table and changing the entry? What
prevents them from looking at the code and seeing the password? What
prevents them from creating an update query and changing the entry in the
field?

The only way to do this type of thing is to implement User-Level Security
and properly restrict the users. Implementing ULS will force the users to
sign on and will allow you (as the developer) to pull in the UserID that was
used to sign in.
 
Thanks, Rick. Yes, my password button is full of holes, for all of the
reasons you have mentioned. I have read about User Level security, but have
never implemented it, or it might have occurred to me to use CurrentUser to
solve the problem rather simply. I assume multiple users can work from a
single front end (at different times) on one computer, each person using a
separate sign-in. Is that correct? Is Microsoft's SECFAQ document a good
resource for implementing security. I also have a link to
www.ltcomputerdesigns.com/Security.htm, which seems to have some good
information. Are there other links or resources of which I should be aware?
Also, after the record has been created, I will want to print a report that
contains signature facsimiles (graphics files, probably wmf) of those who
completed various sections of the report. I plan to do so by linking to the
graphics file. I expect I would use DLookup (based on the name of the
CurrentUser) to do so. Do you see any difficulties with this planned
approach?
 
I am unable to answer a few of your question.

Yes, multiple people could sign in an duse one front-end file. Normally,
we would not recommend this approach. Instead, each user should have a
front-end on their local drive.

As far as other resources, I recommend:

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
 
Thanks again, both for the reply and for the links. I will study the matter
further, and will ask further questions as needed after I have experimented
for a while.

My question about a shared front end is because some computers have several
users (different shifts, for instance).
 
Back
Top