Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Prevent users from seeing other users info 1
- Thread starter jh3016
- Start date
-
1
- #2
bluekestrel
IS-IT--Management
Hi JH
I have written a Purchase Order database and needed to prevent users from seeing other users Purchase Orders but at the same time allow senior Managers to approve purchase orders.
I am assuming as you have multiple users that they will be members of a network and therefore have a User Name.
The code below (tested on Win 2k and XP) will extract the logged on users name from the registry.
*****************************************
Dim strRegValue As String
Dim WshShell As Object
Set WshShell = CreateObject("Wscript.Shell"
strRegValue = WshShell.RegRead("HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Logon User Name"
UserName = strRegValue
*****************************************
You will need to record the UserName when the record is created and this can be done using the same code and recording it in the table along with the users record.
When the users want to view their records I use a form which uses the code to put the UserName in a hidden text box and then I use a sub form and query to filter the records to only show the records that user created.
To allow a supervisor to view all records I would create a different form with a query and subform that will show all records if the logged on user is a supervisor.
Security is very high using this method as you are using the network logon to verify the users identity. This assumes of course that you have prevented users from accessing the database window and design view.
For added security I also add a timestamp field to record the user and time of any changes
********************************
TimeChanged = Now
********************************
Hope this helps
I have written a Purchase Order database and needed to prevent users from seeing other users Purchase Orders but at the same time allow senior Managers to approve purchase orders.
I am assuming as you have multiple users that they will be members of a network and therefore have a User Name.
The code below (tested on Win 2k and XP) will extract the logged on users name from the registry.
*****************************************
Dim strRegValue As String
Dim WshShell As Object
Set WshShell = CreateObject("Wscript.Shell"
strRegValue = WshShell.RegRead("HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Logon User Name"
UserName = strRegValue
*****************************************
You will need to record the UserName when the record is created and this can be done using the same code and recording it in the table along with the users record.
When the users want to view their records I use a form which uses the code to put the UserName in a hidden text box and then I use a sub form and query to filter the records to only show the records that user created.
To allow a supervisor to view all records I would create a different form with a query and subform that will show all records if the logged on user is a supervisor.
Security is very high using this method as you are using the network logon to verify the users identity. This assumes of course that you have prevented users from accessing the database window and design view.
For added security I also add a timestamp field to record the user and time of any changes
********************************
TimeChanged = Now
********************************
Hope this helps
"Security is very high using this method as you are using the network logon to verify the users identity. This assumes of course that you have prevented users from accessing the database window and design view."
Actually, security is nil using this method, even if you hide the database window, unless you combine it with Access user-level security and require users to log on the workgroup. Otherwise, any user can simply create an empty database, link to your tables, and look at or change any data they want.
That's fine if you're only hiding other users' data as a convenience, but if you're protecting against unauthorized reading or modification, you need user-level security. That will require each user to log on to Access, and therefore you can get the user name from CurrentUser() instead of from the registry.
Caution: If you decide to implement user-level security, don't attempt it until you've read all the help topics on it and understand how it works. In particular, use the User-Level Security Wizard and follow the instructions carefully. Playing with the Security menu items can fool you into thinking you've secured the database when it's really wide open.
Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein
Actually, security is nil using this method, even if you hide the database window, unless you combine it with Access user-level security and require users to log on the workgroup. Otherwise, any user can simply create an empty database, link to your tables, and look at or change any data they want.
That's fine if you're only hiding other users' data as a convenience, but if you're protecting against unauthorized reading or modification, you need user-level security. That will require each user to log on to Access, and therefore you can get the user name from CurrentUser() instead of from the registry.
Caution: If you decide to implement user-level security, don't attempt it until you've read all the help topics on it and understand how it works. In particular, use the User-Level Security Wizard and follow the instructions carefully. Playing with the Security menu items can fool you into thinking you've secured the database when it's really wide open.
Rick Sprague
Want the best answers? See faq181-2886
To write a program from scratch, first create the universe. - Paraphrased from Albert Einstein
bluekestrel
IS-IT--Management
Rick
You are of course correct in your statement on security - it was a sweeping statement that I made.
It really depends on the environment you are working in and the security measures already in place and ultimately how critical it is that nobody accesses the data you are trying to protect.
The Purchase Order system I have created is secured by Active Directory and so only trusted users have access to the database - the trusted users would not be able to fool the system as it uses a series of emailed forms to grant
authorisation. These are ultimately auditable from within exchange and whilst a user may be able to access the data table and authorise a purchase order they would not have the required email approval originating from the correct mailbox.
For the purposes of my database the security measures in place are adequate. I always try and build in audit trails and processes that are difficult to work around.
User Level security is only as strong as the password assigned to it and as we all know there are only so many boyfriend / dog / cat / football team combinations you have to try before you get lucky!!
It is always a good idea therefore as well as security to combine audit trails / and stepped processes that will make it difficult for a user to forge if they do get access to your tables. This is also one area of your programming that you should not document too well (or even be misleading)
************************************************
JH
Rick is correct and if it is essential that users do not access the data then this method alone is not enough -
If however it is for convenience then it is a much simpler way than employing user level security.
**************************************************
You are of course correct in your statement on security - it was a sweeping statement that I made.
It really depends on the environment you are working in and the security measures already in place and ultimately how critical it is that nobody accesses the data you are trying to protect.
The Purchase Order system I have created is secured by Active Directory and so only trusted users have access to the database - the trusted users would not be able to fool the system as it uses a series of emailed forms to grant
authorisation. These are ultimately auditable from within exchange and whilst a user may be able to access the data table and authorise a purchase order they would not have the required email approval originating from the correct mailbox.
For the purposes of my database the security measures in place are adequate. I always try and build in audit trails and processes that are difficult to work around.
User Level security is only as strong as the password assigned to it and as we all know there are only so many boyfriend / dog / cat / football team combinations you have to try before you get lucky!!
It is always a good idea therefore as well as security to combine audit trails / and stepped processes that will make it difficult for a user to forge if they do get access to your tables. This is also one area of your programming that you should not document too well (or even be misleading)
************************************************
JH
Rick is correct and if it is essential that users do not access the data then this method alone is not enough -
If however it is for convenience then it is a much simpler way than employing user level security.
**************************************************
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question
