Changing the current user

  • Thread starter Thread starter Gareau, Dany
  • Start date Start date
G

Gareau, Dany

Hi,

I need to change the current user in a secured database (with user level
security). Is there a mean to do so in vba, without closing and opening the
db again ??

Thank you in advance,

Dany


--

_____________________

ZEC Dumoine
Tél.: (819) 762-6660
Fax: (819) 764-6375
www.zecdumoine.ca
(e-mail address removed)
 
I need to change the current user in a secured database (with user level
security). Is there a mean to do so in vba, without closing and opening the
db again ??
Click to expand...

As far as I'm aware this is not possible.
You have to close the secure database and then re-open.

If I was to even make a guess why it was designed this way,
I would say this:

If a user could change *who* they were in Access (essentially
the Current User) through simple VBA then this would just
present a big gaping hole in security for hackers to take advantage of.

(Just a flat-out guess though)
 
As Jeff says, the only way to "change the current user" is to log out,
then log back on as that other user.

However, you can "create a new workspace" as a different user, and
through that workspace, you can perform various operations "as if" you
were that other user. This is not a security hole, because you need the
username *and password* of that "other" user, before you can create a
workspace "as" him.

See the CreateWorkspace method for more information.

HTH,
TC
 
Thank you very much for your quick answer!
I will try to circumvent the problem by follwing your suggestion.
Unfortunatly, this is not a very efficient solution... unless I can close
the database and reopen it automaticaly. I can close the database in vba,
but not reopen it, since the script is terminated following the closure. And
there seem to be a security hole in access 2000 that will cause a problem:
when I close the secured database and immediately reopen it, no password or
user are asked but the db is available (access use the last successful login
I think). I have to close access itself and relaunch it to be prompted a
password. How to do that in vba automaticaly ?? I don't want my users to
have to do it themselves...
 
Why do you want to programatically close the database & reopen it for
some other user? In other words, what are you actually trying to
achieve from an end-user viewpoint?
 
I have a sales database which have to register the current clerk doing the
sales. I just want to have a "logout/login" function. I sure can ask the
users to close/open the database themselves, but I'm afraid that they will
just start it at the begining of the day, and leave it that way by lazyness
for the rest of the day. The databases will be used in a remote region with
almost no supervision, so it must be very easy to use. In addition to sales,
the databases also record all fishing/hunting activity in the territory.
Maybe I'm just going overboard with a secured solution and a simpler one
will do the trick...
 
I believe that if you open a secured database with a shortcut,
then close it by going to File | Close, (it leaves Access still open),
and then subsequently select the file from the MRU list on the
file menu, then the secured database will open back up, but not
present the Login screen. Is that what you are observing?

The key to solving that issue is to make sure the database completely
closes and Access along with it.

You have provided more information on the specifics of your
situation which helps. Reading through that information I now
have a better understanding of the issues involved.

Do you have sensitive information in this database? If not,
one idea is to not implement Access User Level Security and
instead create your own type of security *system* where
the users can simply log in and out without having to close
the database. I did something *similar* for an application a
long time ago. Perhaps this type of setup would work OK
in your situation.

I'm sure there are many other options available as well. I will
try and do some thinking and testing and see if I can come up
with anything.
 
It seems to me that his problem is this. What is to stop user 'A'
walking away from the system, not logging out, and user 'B' starts
using it? Now user 'B' is working under user 'A's logon. That is what
he wants to prevent, IMO. If so, it doesn't matter whether he uses
normal workgroup-based security, or some other (custom) method.

Here's what I'd do. Define the "maximum amount of work" that a user can
perform before he must "revalidate" himself.

* The "maximum amount of work" might be 1,000 keystrokes, or data
entry of 50 records, or 30 minutes elapsed time, or whatever.

* When that amount has expired, make the user retype his password.
If the retyped password is correct, you have little option but to
assume that the originally logged-in user, is still around. Conversely,
if the retyped password is *not* correct, you can assume that the
cxurrent user is working on someone else's login, so the system should
take action accordingly.

If you are using normal workgroup security, the following code will ask
the current user to retype his password. If the password is not
correct, the system will quit back to Windows.

(UNTESTED)

dim sPwd as string, ws as workspace
sPwd = inputbox ("Retype your password")
on error resume next
set ws = dbengine.createworkspace ("", currentuser(), sPwd)
if err.number <> 0 then
msgbox "wrong; goodbye!"
application.quit
endif
on error goto 0

Obviously you'ld want to give the user several tries (not just one, as
coded above) - but you get the idea.

HTH,
TC
 
It seems to me that his problem is this. What is to stop user 'A'
walking away from the system, not logging out, and user 'B' starts
using it? Now user 'B' is working under user 'A's logon. That is what
he wants to prevent, IMO. If so, it doesn't matter whether he uses
normal workgroup-based security, or some other (custom) method.

Here's what I'd do. Define the "maximum amount of work" that a user can
perform before he must "revalidate" himself.

* The "maximum amount of work" might be 1,000 keystrokes, or data
entry of 50 records, or 30 minutes elapsed time, or whatever.

* When that amount has expired, make the user retype his password.
If the retyped password is correct, you have little option but to
assume that the originally logged-in user, is still around. Conversely,
if the retyped password is *not* correct, you can assume that the
cxurrent user is working on someone else's login, so the system should
take action accordingly.

If you are using normal workgroup security, the following code will ask
the current user to retype his password. If the password is not
correct, the system will quit back to Windows.

(UNTESTED)

dim sPwd as string, ws as workspace
sPwd = inputbox ("Retype your password")
on error resume next
set ws = dbengine.createworkspace ("", currentuser(), sPwd)
if err.number <> 0 then
msgbox "wrong; goodbye!"
application.quit
endif
on error goto 0

Obviously you'ld want to give the user several tries (not just one, as
coded above) - but you get the idea.

HTH,
TC
Click to expand...

Interesting comments TC. I would have to agree with everything you wrote.
We use a POS system at one of locations that requires each server to
log in with their ID number. When we have more than one server on
duty, they sometimes have to use the same terminal. Normally we leave
a screen area on that shows that server's tables. Naturally, if another
server comes along and does not exit out to the login screen, then any
sales rung in will be under the wrong server. This does happen once in a
while. We just have to remind people to log out if more than one server
is on. You can never completely remove the human element in the equation.

Your idea of verifying the user's password is a really good idea, but
coming up with an implementation routine could be the tough part as
you mentioned.
 
Jeff Conrad wrote:
(snip)
Your idea of verifying the user's password is a really good idea,
Click to expand...

Well, that goes without saying!!

but coming up with an implementation routine could be the tough part
Click to expand...

I think it would depend on how many main or commonly-used forms &
reports the system had. If it had one data entry form, & one query
form, for example, you could define the maximum unit of work as "50 new
records and/or queries". That would be easy to code.

But as the OP seems to have disappeared, we will never know :-)

Cheers,
TC
 
Hello JC and TC! I must thank both of you for your help. Your suggestion
have been very helpfull! I will implement a hybrid system for the database;
I will use user level security to segregate roles in the database (clerk,
manager, territory administrator, gamekeeper, etc. ) and use a custom system
for sales. I have a high number of forms (about fourty), so the "maximum
units of work" idea must be implemented with a timer and a forced login
every hour or so. Thank you again for your help!
 
One last thought about the "maximum unit of work".

It seems that you have many forms. Just have the AfterUpdate and
AfterInsert events (of each form) call a common procedure in a standard
code module. That procedure could increment a counter, perhaps a
module-level variable within that module, then make the user
re-validate when the counter exceeded 50 (or whatever).

By that means, you could have a "number of records"-based unit of work,
with not much code, even having many forms.

HTH,
TC
 
Back
Top