Login in dynamically

[John]

Hi all!

I'm playing with this security stuff (kinda kool), however I'm already
facing problems. I would like my Access db program to open always in
read-only mode for everything (so nobody can change the data). So I have
made the default "Admin" and its group to read-only permissions. However,
when the person needs to edit some data in any form I would like them to log
on as another user (user and passw) without re-starting Access. So I would
like the db user to be changed from that point on.

I do not see any method to do this "dynamic switch of users" without closing
or re-loading the application. I appreciate any ideas or suggestions. Thanks
in advance!

-J

 

[Chris Mills]

No. NO.

Restrict them to forms and alter the form fields Enabled/Locked or something.

You can't muck with signons or ULS in a production environment.
Or not reasonably.

Even if you could, what would happen? They'd be thrown from where they are
into a new instance of the MENU of the app? What's that? two clicks less than
closing and reopening?

Chris

 

[John]

Nice! So what I do is to allow them to logon using Access logon at startup.
All the forms will have disable edits, until the user clicks on my "edit"
button and I'll prompt the user for a user name and password. Then through
some VB ADO code I verify the information and unlock the form (allow edits).
Sounds good (but I'm not totally clear about the code part, checking on
permission to an object through code...I'll have to research that).

My manager was very concern about the application running on different
machines and left unattended by their users and he wanted to enforce
security as per transaction and not per application session. That's why he
insisted in opening it logged in as a read-only user, and updating it as a
user with write permissions (without having to close or reload Access).
That's why I was thinking on something like braking the connection (some
how) and have Access re-establish it through a logon screen without
reloading Access. I was exploring options like:
Application.CurrentProject.AccessConnection.Close

I could write an entire application in VB, which would allow me to connect
and disconnect successfully different times with multiple dynamic logins,
but the Access platform is faster and less code consuming for this kind of
stuff.

what do you think?

 

[Chris Mills]

Nice!

What, Access or Me? If Me, Then Ta! )))

So what I do is to allow them to logon using Access logon at startup.

It is not realistic to do otherwise than log them into Access ONCE in a given
session. Well it's impossible but I don't like that word, it's not needed
anyway. You say you are playing with it (which means to me you're not really
experienced with it), which is great of course, but I'd suggest finding out
what can be done or how it works before trying to invent your own schemes. My
impression is that your scheme WILL NOT WORK, even if it was possible.

All the forms will have disable edits, until the user clicks on my "edit"
button and I'll prompt the user for a user name and password.

Yes, to the first part. I've done that where it's critical (not often). The
code to alter Enable/Locked is not very difficult, and fancier code can even
determine dynamically what fields there are on a form (no need to worry if you
add more fields).

No. Never a good idea to prompt again for a password. I might in some
Menu/System/End-Of-Year Rollover scheme (something unrecoverable, or something
only to be done with the Developer on the telephone) but not otherwise. This
sort of security (changing from RO to RW), In My Humble Opinion, is either
different from or nothing to do with the provisions of Access ULS.

Access ULS says, this particular user (actually you'd set permissions to a
Group they join) can either have RO or RW to something. If they do they do,
and if they dont they dont, and so far as I know everyone is happy with that.
I mean, there's enough damn security permissions to set, how many do you want
in ULS if they "can in these circumstances and cant in those".

Then through
some VB ADO code I verify the information and unlock the form (allow edits).
Sounds good (but I'm not totally clear about the code part, checking on
permission to an object through code...I'll have to research that).

Yes. I use DAO but that's just a detail. This doesn't involve any DAO or ADO.
Me!SomeField.Enabled = True
Me!SomeField.Locked = False (if only one set, you get Greyed)
....or vice versa...long list unless you use code to auto-find all the fields.

My manager was very concern about the application running on different
machines and left unattended by their users and he wanted to enforce
security as per transaction and not per application session.

Well, I've seen sites where they go to lunch, or home, probably in the middle
of a transaction too. Never mind security, they might corrupt Access if it's
rebooted overnight! Stick a label in the middle of the screen or something;
there's only so much one can do to teach operators good practise (Computers,
not just Access)

That's why he
insisted in opening it logged in as a read-only user, and updating it as a
user with write permissions (without having to close or reload Access).

His idea is reasonable. Insistence over what a developer can do and how to do
it may not be.
I said how to secure it. Make sure they only have access to Forms (that's
another subject, things like AllowBypassKeys), then you can control
dynamically the access provided by the form.

But this is surely one of many worries? I still have some apps which are
"Unbound Forms" (not bound to a table and I have to do all programming/control
myself). Now I only use Bound Forms (much less work), but Bound Forms do
standard Access things (like, if you move off a record it is saved with no
prompt). I say, get used to it, I don't have time to program Unbound Forms.

That's why I was thinking on something like braking the connection (some
how) and have Access re-establish it through a logon screen without
reloading Access. I was exploring options like:
Application.CurrentProject.AccessConnection.Close

I don't recall anyone successfully posting how to change a UserID in one
session. Even if they did, who are you gonna ascribe the CurrentUser who
changed the form to? (that's the best way to track who/when changed data)

I could write an entire application in VB, which would allow me to connect
and disconnect successfully different times with multiple dynamic logins,
but the Access platform is faster and less code consuming for this kind of
stuff.

what do you think?

You could, but I don't believe VB coding would be any less than Access coding
(overall, not this specific aspect). VB coding is more because it creates an
exe, gets rid of half the Access bugs, easier to install, might be more
"independent", things like that.

You are concerned about a security level (locking or unlocking forms) which to
my mind is UNRELATED to ULS. Or, 100,000 programmers can't be wrong.

Can they?

Cheers
Chris

 

[John]

Thanks a lot Chris! Very very helpful!

What, Access or Me? If Me, Then Ta! )))


It is not realistic to do otherwise than log them into Access ONCE in a
given
session. Well it's impossible but I don't like that word, it's not needed
anyway. You say you are playing with it (which means to me you're not
really
experienced with it), which is great of course, but I'd suggest finding
out
what can be done or how it works before trying to invent your own schemes.
My
impression is that your scheme WILL NOT WORK, even if it was possible.


Yes, to the first part. I've done that where it's critical (not often).
The
code to alter Enable/Locked is not very difficult, and fancier code can
even
determine dynamically what fields there are on a form (no need to worry if
you
add more fields).

No. Never a good idea to prompt again for a password. I might in some
Menu/System/End-Of-Year Rollover scheme (something unrecoverable, or
something
only to be done with the Developer on the telephone) but not otherwise.
This
sort of security (changing from RO to RW), In My Humble Opinion, is either
different from or nothing to do with the provisions of Access ULS.

Access ULS says, this particular user (actually you'd set permissions to a
Group they join) can either have RO or RW to something. If they do they
do,
and if they dont they dont, and so far as I know everyone is happy with
that.
I mean, there's enough damn security permissions to set, how many do you
want
in ULS if they "can in these circumstances and cant in those".

Yes. I use DAO but that's just a detail. This doesn't involve any DAO or
ADO.
Me!SomeField.Enabled = True
Me!SomeField.Locked = False (if only one set, you get Greyed)
...or vice versa...long list unless you use code to auto-find all the
fields.


Well, I've seen sites where they go to lunch, or home, probably in the
middle
of a transaction too. Never mind security, they might corrupt Access if
it's
rebooted overnight! Stick a label in the middle of the screen or
something;
there's only so much one can do to teach operators good practise
(Computers,
not just Access)


His idea is reasonable. Insistence over what a developer can do and how to
do
it may not be.
I said how to secure it. Make sure they only have access to Forms (that's
another subject, things like AllowBypassKeys), then you can control
dynamically the access provided by the form.

But this is surely one of many worries? I still have some apps which are
"Unbound Forms" (not bound to a table and I have to do all
programming/control
myself). Now I only use Bound Forms (much less work), but Bound Forms do
standard Access things (like, if you move off a record it is saved with no
prompt). I say, get used to it, I don't have time to program Unbound
Forms.

I don't recall anyone successfully posting how to change a UserID in one
session. Even if they did, who are you gonna ascribe the CurrentUser who
changed the form to? (that's the best way to track who/when changed data)

You could, but I don't believe VB coding would be any less than Access
coding
(overall, not this specific aspect). VB coding is more because it creates
an
exe, gets rid of half the Access bugs, easier to install, might be more
"independent", things like that.

You are concerned about a security level (locking or unlocking forms)
which to
my mind is UNRELATED to ULS. Or, 100,000 programmers can't be wrong.

Can they?

Cheers
Chris