Groups, Passwords, and lot's of files

[ddreese]

Right now I have no groups set up on any of my files. I have two passwords for each file, one for Administrator (me) use, and one for staff use. I basically let them add/modify/ and in some cases delete the records, but not fancy stuff like editing scripts or exporting data. That sort of stuff.

I read a cool article in the FM Advisor magazine recently about using groups, which I've never done before. I have a rather simple login process right now to authenticate users to the database. They enter their username and password, and it then checks a user.fp5 file I have to make sure their information matches. It works well for what it is, but to add any more 'cool' features like you can do with groups, it's going to be way too cumbersome.

Is there a way that I can set the 'status (currentGroups)' manually to the value of a field in their user record when they successfully log on? And then if I do and open up these other files (say I have a default password of blank associated with each group but my own), will their group privileges carry over?

I think I understand how using just groups would work, but I also really like the fact that I track who it is currently logged on (because of some transaction files that I keep).

Does this make sense to anyone?

[Fenton]

You can't Set groups. It's a calc function, Status(CurrentGroups), and it must be Unstored. It really works the other way around.

Each Group is tied to 1 or more passwords, via the Access Privileges. So, in order to identify a single person using groups, you have to have 1 password per person, assigned to 1 group.

It's a pain to set up for a lot of people, but provides pretty good security once it's done. They can change their password, that has no affect on the group (which is why FileMaker has the 2 levels).

It's really a different system from a custom made Login routine that uses names and passwords entered into your fields.

The groups method is best suited for higher security, low number of users, low number of files scenarios.

It can be combined with limited record access privileges (actually either method could).

There is a plug-in, by New Millineum, which can set passwords across a solution.

http://www.nmci.com/

[ddreese]

Thanks for your input! I'll probably just end up doing some conditional scripts to secure different parts of the database. I was just hoping there would be an easier way Thanks again!

[Steven H. Blackwell]

A couple of cautionary notes. RLA and groups work well together, but their joint use can cause conflict and unexpected results. Generllay speaking, Group privileges trump RLA privileges. That is, if a field is marked for read only in Groups Access overview, and its RLA calc evaluates to true, it can NOT be edited. Juist watch this carefully, and you should be OK.

Additionally, I want to caution against the use of so-called log-on files. They are almost always profoundly insecure, and they introduce insecurity into previously relatively secure files. use them with extreme caution.