Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 8799 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

I am starting to set up a security system for my database. I am trying to feel out how I need to go about this. Here is the cirteria, and I would appreciate any suggestions. Thank you.

When it is completed, there will be around 25 - 30 databases.

For now there will be ten users, soon there will be many more users on the server version.

I want to be able to either have each user have specific abilities or have about fifteen groups. But if I have the groups I still need to be able to track each individual user's time spent on particualar proects. If I use groups I guess I can use the user name of the different applications to triack their time. However, if somebody is on a different computer, they cannot be tracked by the application's user name, because it will be somebody else's.

I don't know the different senario's for security logic, but I'm wondering if it is possible to have the database open to a security database that has records of every person and their authorization levels for different files. The opening layout would be like most, asking for a username and password. Then all the files that person is authorized to use opens up specific to their authorization level. Then even if the user closes a file and opens it later, an opening script for that file checks that person's username and reopens it to their authorization.

It seems to me, although I don't know if it can be done, that the best and simplest way to do this is to make the twenty or thirty groups with the appropriate levels assigned. Then from the username/password database, the adminsitrator will assign each record to a particular group. Then, when a person logs in, that record is what all the files will use as the group and password.

Again, I am new to Filemaker and databases, and very new to this aspect of it. I am looking for feedback and advice of any kind of the different logic reasoning for security. Is what I'm describing doable?

PS - One thing I am fuzzy on is - it looks like if I open a file with a password, I am not asked for a password on other files, they just open. I an not sure what the criteria is on this. Does just the password have to match, or just the group name, or the password abilities, or the group abilities, or a certian combination, or does everything have to match?

Thank you very much for any help.

Posted

quote:

Originally posted by [email protected]:

I am starting to set up a security system for my database. I am trying to feel out how I need to go about this. Here is the cirteria, and I would appreciate any suggestions. Thank you.

When it is completed, there will be around 25 - 30 databases.

For now there will be ten users, soon there will be many more users on the server version.

I want to be able to either have each user have specific abilities or have about fifteen groups. But if I have the groups I still need to be able to track each individual user's time spent on particualar proects. If I use groups I guess I can use the user name of the different applications to triack their time. However, if somebody is on a different computer, they cannot be tracked by the application's user name, because it will be somebody else's.

I don't know the different senario's for security logic, but I'm wondering if it is possible to have the database open to a security database that has records of every person and their authorization levels for different files. The opening layout would be like most, asking for a username and password. Then all the files that person is authorized to use opens up specific to their authorization level. Then even if the user closes a file and opens it later, an opening script for that file checks that person's username and reopens it to their authorization.

It seems to me, although I don't know if it can be done, that the best and simplest way to do this is to make the twenty or thirty groups with the appropriate levels assigned. Then from the username/password database, the adminsitrator will assign each record to a particular group. Then, when a person logs in, that record is what all the files will use as the group and password.

Again, I am new to Filemaker and databases, and very new to this aspect of it. I am looking for feedback and advice of any kind of the different logic reasoning for security. Is what I'm describing doable?

PS - One thing I am fuzzy on is - it looks like if I open a file with a password, I am not asked for a password on other files, they just open. I an not sure what the criteria is on this. Does just the password have to match, or just the group name, or the password abilities, or the group abilities, or a certian combination, or does everything have to match?

Thank you very much for any help.

First of all it sounds like the best solution for you is going to be to have a users file that the users have to log into. You can make this a bit easier on them by using the default user name in FileMaker prefs, but to allow people to access the database from other machines, just make it so that when the come in, the user name is shown to them, and they can change it to another one if they are somebody else. Then they enter the correct password and access the system just as if they were at their own computer.

Regarding the opening of files with the password, if the file you are in does something that will open another file (displaying a related field, running a script with the Open command) and the second file has the same password as the first, the second file will open with the password that was used to open the first.

Does that all make sense?

Chuck

This topic is 8799 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.