Implementation structure

[panchristo]

What is the common procedure/structure for implementing a users management table inside a solution? (not using external server to authenticate)

I mean, if someone would like to use a custom login screen as well as provide a custom UI for the management of accounts and users (add/delete, reset passwords, assign privileges etc)?

What aspects of security do need to be considered?

Can anyone provide a complete model for that?

[Steven H. Blackwell]

First, maybe read this article on FM Forums about the dangers of Ersatz Security Systems.

Second, don't store passwords in data fields. Third, don't use data fields as the underpinning of your role based privileges management.

Steven

[panchristo]

Hmm, interesting. Useful to know. Thanks a lot.

But how do you usually create a "nice" GUI integrating the abilities usually wanted?

Or does all this mean that everytime the customer wants to add an account needs to re-hire the developer? (I hope not...)

I apologize if my questions are childish, please tolerate them...

Last minute question: Would an encrypted field for storing account and privilege info solve the problem? Also does all that mean that a separation model is the way to go?

Edited May 27, 2010 by Guest

[David Jondreau]

It's not clear what you're trying to accomplish.

What is wrong with the Manage Accounts dialog for managing users?

[panchristo]

Basically, I'm in the learning process...

Trying to figure out what is the correct and safe way to go. I'm not a professional developer, just an amateur with growing plans.

I'm currently developing for my own needs, but soon enough I am going to develop small scale applications for a small number of users at work (~10 people), and I'm trying to plan my next steps.

What I would like to do is to have a UI to manage accounts not by me (so-caled developer) but simple users (not privilige-wise).

[Vaughan]

It's OK to have a table that stores the user names. Do NOT store passwords in it.

Use the built-in script steps to create and delete user accounts. To add a user account you'd prompt for a username, check it is unique, create the record in the Users table and use the Add Account script to create the account in the database with a default password that is set to require changing on first login. That way there is no need to know the user's passwords. When the account record is deleted from the Users table use the Delete Account script step to delete the actual account from the file. This keeps the Users table and the actual accounts in sync.

Use record level access privilege sets to control access, don't try to tricky things with scripts and global fields to control access: they do not work.

The developer will be needed whenever a new privilege set needs to be created, but for everything else the users can do it themselves.

OTOH external authentication is quick and easy and not just for big organisations. I set up an art gallery with EA a month ago, they have just 4 users but the database solution consists of 21 files. Automating account management in 21 files is too much work.

[panchristo]

Now we re talking! GREAT!

Thanks a lot, I'm somewhat relieved now - this is what I was thinking of in the first place.

I'll proceed that way.

Any more ideas are still welcome however!

[Steven H. Blackwell]

As Vaughan says, I would highly recommend External Server Authentication.

From right here in FM Forums,

this article might be useful as well as this one.

Steven