Allow viewing of records they created only

[macaroni]

I have a solution that I'm trying to work out the security.

What I am attempting to do is users will have on their desktops a filemaker 7 file that will open the solution files from the server. Since I have multiple users, I would like to impose the security of the users only have the ability of viewing the records they have created. If they did not create the record

then the records can't be seen at all to the point that if they do a show all, only records that they have created will be shown.

I'm hopping that this is possible and I have a feeling it is.

Can anyone point me in the right direction on where the security priviledges this might be done or is this something I have to manage in my scripts.

Thanks.

[Fenton]

Most of this can be handled by a Record-level restriction of privileges for each of those Accounts. Each person must have their own account. Account creation/deletion can be scripted, so this is not tedious. That way Get(AccountName) is going to identify them. You would auto-enter the same into a field on creation of new records, so they'll be marking their own as they go.

There are a couple ways to do this. One is to use a separate file with a portal so they can only see their own records. That imposes some limitations on your interface however. Another method is to just let 'em into the file. They cannot get past the restriction in any case. But they will see <<no access>> tags in the fields, unless you perform a script at startup to isolate their records.

You'd probably run this from another file. There's a kind of Catch 22 that happens when they open the restricted file. Which is that if it opens on a record that does not belong to them (likely), they have no access to it, so can't do anything. Hence beginning from the other "Login" or "Menu" file, where they have an account, but no record-level restriction.*

Once they're on a record that belongs to them everything works fine. When they do a Find, the <<no access>> records are omitted automatically. The only problem is with Show All Records. You can use your own button and script, and use a self-relationship with a calculation field (unstored), Get(AccountName) the creation name field to Go To Related Record [show,

AccountName relationship"].

Administrators who have full access to all records can have the normal Show All Records. Trap for them using the Get(PrivilegeSetName) function. You will have a lot of Accounts, but only a few Privilege Sets.

I'm going to post a new sample file to do scripted creation of Accounts, in the Sample files forum. As soon as I make tea -)

(P.S. Personally I would not put passwords in the opener file(s) themselves. Because there will be many of them, distributed all over. It's both a pain and a security risk. Those files should open as Guests only, no password, then target a centralized Login file on the server computer, where all the accounts and passwords are in force; which would trigger the Account/password dialog. That may be what you meant.)

*If someone knows how to manage startup within the same file, when they have no access to the current record, please let us know.

[Reed]

What would you say is the best way to automate the synchronization of accounts in two separate files:

Say you have a resource scheduling database (one file) and a resource usage tracking database (one file).

The resource usage file contains a users table which is also accessed by the schedule via file reference. A simple looping script in each file can then create identical account sets in each file where the account name is calculated from the first 3 letters of first and last names (MI added if necessary) The password is initially set to a random string that is stored in the users file (maybe not the best security-wise). Then the user is forced to change the password at first login to the tracking file.

The catch is that this does not automatically change the password in the other file. Is there a way to create a startup script that automatically changes the schedule password to the resource tracking password?

I'm currently working on the scheduling part as an IWP solution and the usage tracking part as a kiosk. The users will not be able to change their passwords via IWP, since dialogs don't really work.

Anyway, it's late and I'm tired.

Dana

[Fenton]

Sorry, I didn't see this message until today. My advice is not to use the "make the user change the password at next login" option. Because then I can't see how you can control the scripted process to Reset the pw in the other files. That's the script step you want to run, Reset.

You can just set a Flag field which means, "Need to run the Reset pw script next time." Then you retain control. They enter their new password into a global field, in a Custom Dialog. You use it to Reset that Account in all files. Then delete it and the Flag.

[Reed]

Is storing passwords, even in temporary globals, a good idea if the fields aren't encrypted? I know that globals don't persist in a multi-user environment when the session ends, but can you see any way that someone could sniff passwords this way?

[Fenton]

Perhaps it's not the safest thing. It's a Catch 22. You can't script the process of setting passwords unless the pw is in a regular field, if only for a microsecond (the Reset is fast). You do not have access to it otherwise.

Alternatively, if you use the built-in "user changes password" then FileMaker can protect it,* but then you can't script resetting it into other files.

What would be ideal is if FileMaker had an option to tie those 2 steps together, allowing you pass the new password directly to the Reset script in an encripted form, to use in other files. It sounds somewhat complex; but it's an obvious thing you might want to do. "Complex, but might want to do" doesn't always make it into the application though.

An obvious solution is to only have 1 file on the web. That way you can just use the built-in "new password" step. I think that's the only way you can be really "secure."

*(at least as secure as FileMaker 7 is, which, to my limited understanding, is fairly secure).

I'm sure there are ways to do it using Custom Web Publishing (I don't know, but entire technologies are based on this). But we're talking simple IWP.

Inside an office network, with multiple files, a global field which only existed for a split second then was emptied seems like a fair trade-off.