Security - use internal or make own ?

[Nick Alexander]

What's the consensus on whether or not to use the internal security model or
make one's own...is there a generic set of Add New User, Maintain Existing
User, Change Password functions...I don't want my Customers to have to go
through the Tools, Security stuff, on the Main db menu...all views
appreciated.

Thanks in advance.

--
Nick Alex
Bigstep Software
UK

[Stephen Witter]

We are using access security and I created a form for allowing users to
manage thier own passwords.
Pretty easy and access security is good if done properly.

Look up "permissions" in access help for ideas on how to code security.

The code to change a users password (for example) is:
DBEngine(0).Users(CurrentUser()).NewPassword "their old password", "their
new password"

Look up securityms knowledgebase or
"Nick Alexander" <nick...@btinternet.com> wrote in message
news:b04vei$abi$1...@venus.btinternet.com...

[Larry Linson]

Breakable as Access' own security is, it is far more secure than any
"roll-your-own" arrangement. There are good examples of programattically
interfacing with security in the _Access Developer's Handbook_, by Litwin,
Getz, et al, published by Sybex.

"Nick Alexander" <nick...@btinternet.com> wrote in message
news:b04vei$abi$1...@venus.btinternet.com...

[Albert D. Kallal]

Setting up security and making it a user friendly type system for a
end user who will eventually have to manage the system is not hard.

However, it does take planning on your part.

You can teach the admin to how to use the security settings. however, to
make things easy, you as the designer probably want to setup things up
before hand.

For example, you can have the admin add a new user, and then start adding
what forms that user can use. That is going to be a LOT OF work if you have
100 forms. Also, if you allow the client to do that, then every time you
send a update, they will loose the security settings.

Hence, the best approach is to sit down and make up a bunch of
security groups. For my last project the groups I made where:

Basic user
Daily Reports
Seasonal Reports
Allow creation of Corporate Groups
Can forward date invoice payments
Can back date invoices payments
Can delete invoice payments
Add Tours, Rooms, Change Tour Pricing
Admins Administrator (Add users, change passwords)

As you can see, I sat down and made a bunch of security groups. So, for
example, in the above list I have something called seasonal Reports. Only
those users that need to view financial sales data for the year can thus use
those reports that have financial data. The same goes for only some users
can back date invoice payments. Of course most employees are not allowed to
back date invoice payment, and thus the daily sales slips, and the till MUST
be balanced at the end of the day. (if not, the employees must stay until it
is balanced).

The above idea of creating a bunch of security groups makes the whole thing
much easier. Now, all you have to do, is add a new users to the system (you
can use the security menu). You then simply add each group above to the
user. Most standard users get basic, and perhaps daily reports. In addtion,
this means you NEVER actually have permissions for a user set in the
the actual applction. (that way, you can even send your client a new update
and the existing secuirty settings will NOT be lost).

The real work in setting up the security is thus sitting down, and making a
bunch of sensible security groups. After that, the admin can quite easily
mange the whole system, even with the built in security system.

I actually did not like the security menu in ms-access, and thus I did write
my own. You can see some screen shots of this at:

http://www.attcanada.net/~kallal.msn/RidesSec/index.html

However, as mentioned the screens are not hard..it is sitting down and
making up some security groups is the hard part.

--
Albert D. Kallal
Edmonton, Alberta Canada
kal...@msn.com
www.attcanada.net/~kallal.msn

[Nick Alexander]

Albert et al,

I very much appreciate your valued response....obliged to you !

Nick

[Nick Alexander]

Looks like just what I need, Albert...any chance of getting the forms/code,
please, to save me re-engineering your solution from scratch ? I guess it's
all table driven, right ?

I tried to mail you direct but it bounced.

Thanks in advance,

Nick

[Albert D. Kallal]

The only part that is table driven is the description for the security group
options, and also a simple users table for full name and initials. All other
security stuff is taken from the workgroup file. All passwords etc remain in
the workgroup file.

Remember, the hard part is creating those security groups. You NEVER want to
assign a form to a user, but ALWAYS to a security group. If you keep this in
mind, then you can actually update the front end to your application for a
client, and they will NOT loose any security settings (because you always
assign forms/reports etc to your careful chosen groups). That way, you
decide what group each report/form belongs to when you *create* them.

I have zipped and emailed you a copy.

[Nick Alexander]

Albert,

Just a public note to say THANKS ! That was EXACTLY what I needed...saved me
a couple of days, I reckon !

Nice code !

Thanks again,
Nick

[Nick Alexander]

Thanks for that, Stephen, but Albert's solution is really great ; I already
had a Sub to change the pw ... you should SEE Albert's solution...it's
awesome !

Nick Alex