Re: Securing a signature field

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

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



--
Rick B



"BruceM" <bamoob@xxxxxxxxxxxxxxxxxx> wrote in message
news:eSKd2d2RGHA.4384@xxxxxxxxxxxxxxxxxxxxxxx
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?

"Rick B" <Anonymous> wrote in message
news:e%23ZrrMuRGHA.1236@xxxxxxxxxxxxxxxxxxxxxxx
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.

--
Rick B



"BruceM" <bamoob@xxxxxxxxxxxxxxxxxx> wrote in message
news:%23i6VoEuRGHA.4452@xxxxxxxxxxxxxxxxxxxxxxx
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.







.

Relevant Pages

  • Re: Securing a signature field
    ... I recommend: ... The Security Whitepaper is also worth reading to help you understand. ... Are there other links or resources of which I should ... I will be splitting the database. ...
    (microsoft.public.access.security)
  • Re: setting a password on a button on the switchboard
    ... Could you send me the sample database for the fourth option (4. ... > Security in an Access database can probably be broken down into two big ... > points about being easier than User Level Security, ... > What type of data are you trying to protect? ...
    (microsoft.public.access.forms)
  • Re: access 2003
    ... security in access 2003. ... The data will go on the server and the program database ... than the alternative of creating an mde file. ... MDW file from the written record. ...
    (microsoft.public.access.conversion)
  • Re: access 2003
    ... security in access 2003. ... The data will go on the server and the program database ... than the alternative of creating an mde file. ... MDW file from the written record. ...
    (microsoft.public.access.conversion)
  • Re: Is this possible??
    ... I understand Windows security but since I've not seen A2007 live, ... The backend is on the server in it's own file. ... database, but everyone does not need to have access to tblwage which is ...
    (microsoft.public.access.tablesdbdesign)