Jump to content

Account propagation to other files in FM7


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

Recommended Posts

This is a continuation of this tread . Thought I should move it here for a continued discussion about an algorithm for propagating account and password changes to multiple files in FM7.

Fenton & Vaughan,

If I understand the algorithm correctly, this is how it works:

New Account

The name of a new account is entered in a field

The password for that account is entered in a field

A group is selected for this account

A new account is created with that name, password, and group in the current file

A new account is created with that name, password, and group in every other file

Change Password

A global is set with the current account name

The user enters a new password in another global

The account is reset with this account name and password in the current file

The account is reset with this account name and password in every other file.

So for a user to change their password would require opening all files. I have about 85 files in my current FM6 solution, and I don't expect to be able to combine these all right away when I migrate to FM7. Won't opening this many files be a problem (over a WAN)?

Thanks

Link to comment
Share on other sites

"A group is selected for this account"

FMP 7 uses privilege sets instead of groups, but yeah you've got the idea.

" I have about 85 files in my current FM6 solution... Won't opening this many files be a problem (over a WAN)?"

No more a problem than it was in FMP 6. Adding the scripts into all 85 files will be more of a challenge, only because it'll be a bit repetitious.

In the security demo I posted I built a "UserNames" table to hold the accounts. The fields for username, password and privilege set are all in the UserNames table.

Link to comment
Share on other sites

Thanks Vaughan,

In my current solution, files are opened as needed. Too slow to open all files at login.

Well, I can add open steps to my FM7 converted files and test the speed of their opening all at once.

Two important things I came across when I was testing the built-in FM7 security: In OS X, the login dialog has an option for changing the password and an option to add to keychain (so it can automatically login in the future.)

For a multi-file system to handle accounts properly, users should not be able to change their password from the FM7 login dialog--it would only change for one file.

The keychain thing can cause problems on multi-user systems (like classroom with multiple teachers). Sure, I could setup multiple OS X accounts, but it seems more likely users will want to share an OS X account. Users could set the keychain to log them in automatically, allowing other users access to their account. And the keychain information (name and password) is stored in plain text in the system, easily accessible with the Keychain Access utility.

These two issues imply needing a default FM7 login with a custom login screen to get the user into the system. Is my reasoning correct?

Link to comment
Share on other sites

Different people access different parts of the system. When HR staff go to staff screens, related staff files open as needed. When teachers go to the class/student screens, related student files open as needed. My assistant and I are the only ones who access all parts of the system, and we rarely run into the 50 file limit.

Link to comment
Share on other sites

One of the seriously cool things about FMP 7 is that referenced files are not "opened" in the FMP 6 sense, they don't appear in the Window menu.

Link to comment
Share on other sites

Ender wrote:

Two important things I came across when I was testing the built-in FM7 security: In OS X, the login dialog has an option for changing the password and an option to add to keychain (so it can automatically login in the future.)

For a multi-file system to handle accounts properly, users should not be able to change their password from the FM7 login dialog--it would only change for one file.

-------------------------------------------------------

This is one reason why you want to set up a single file to script such things. Actually, if they changed their password in the opening file, they would have to change the password in all the files, one at a time, at login time, hopefully with no typos, because the new one wouldn't match the old. Not a pleasant task for 85 files.

I'm amazed at the speed of account creation. I'm only doing about 5 files at once, but it's practically instantaneous. It does appear to open the other files however. But you could add a step to either Hide or Close them afterwards.

I don't see that you'd need a custom Login file/screen, unless you wanted it for other reasons. The Account login is the built-in FileMaker dialog. The separate file for handling Accounts is, in my case, the file where the staff are, since that's where there names are. It seemed a logical place to run from.

In my case I'm creating an Account for each staff person, each with their own password, so I can know who they are via Get ( AccountName ). I'm glad it's easier to do than it was in 6.

As far as security goes, it's a little risky to store the passwords in the file itself. After the accounts are created, there's no real need to keep them. You could just delete them, after printing them once, memorizing, then eating the paper ???-)

The most secure system would build a similar mechanism to allow/force each user to change their password, placing it temporarily into a global field in order to propagate through the system, then deleting it immediately.

Link to comment
Share on other sites

Fenton said:

The most secure system would build a similar mechanism to allow/force each user to change their password, placing it temporarily into a global field in order to propagate through the system, then deleting it immediately.

This is what I have in mind. But for the reasons I indicated, I think the FM7 login dialog has to be avoided.

Link to comment
Share on other sites

As far as any users changing their password, that can be set to off in the privileges. When administrators need to change anyone's/everyone's passwords the script can run with full-access privileges, so it still works.

You're right that there doesn't seem to be any way (that I can see) to stop people from storing the PW in their Keychain. If the Keychain is properly locked I don't see that as a big security risk (I could be wrong).

I can see that in your situation, where you have a lot of users, sharing the set of privileges, that a custom login is attractive. I suppose you could use the custom login to determine what their access level is, then use the Login script step to log them in with the built-in security.

There is, as far as I can see, no way to have several people share the same "group" (v.6), with separate passwords. I don't really see the point in that anyway, since you can't then access the people separately.

It appears to me that every unique password in 7 requires an account; I don't think you can have more than 1 password per account (?); and account names must be unique. We're lucky they made scripting this possible or we'd go crazy for sure.

The solution I'm working on currently has only a few people, with a requirement to stop some of them from even looking at others' records. It makes sense to script separate accounts for each and use the built-in security.

Link to comment
Share on other sites

Well, I tested the speed to open 60 files being server on Server 7 with an open script. It took 3-4 minutes on both the LAN and the WAN (256K DSL). I don't know how this compares to FM6 opener script speeds, except I know that our 300-500MB files can take a couple minutes each to open on a WAN.

Another option I'm looking at is using Directory Services from an external authentication server. If I can just figure it out...

Link to comment
Share on other sites

This topic is 7266 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.