User name vs. passwords/groups

[aricm]

I'm writing a database system of about 12 files that will be accessed by several users, each of whom requires a different password. I will also need to control access to different layouts by use of groups. I'm resigning myself to maintaining a password for each user, and tying each of these to the group rights.

However, in several cases I also need to access the user name of the person modifying the database. For example I have a script to add a note to a related "notes" field which accumulates several notes(like a large memo field including all of the notes). In that field I need to insert the username prior to the note text.

I see that the auto-enter options for a field can access the username (which I assume is the network login) to put it into a field. Is there a way to access this value in an InsertCalculatedValue() script step?

I'm hesitant to create a Users database since the client will already have to manage network logins and Filemaker passwords and groups through two different interfaces. A Users database would create a third separate interface.

BTW: the database is running via FM Server on an NT network.

[Ocean West]

Hmmmm... Sounds like this is a SECURITY ISSUE

Moving topic

[DykstrL]

One option you might want to consider is an enhanced "Open" file that you could distribute to your users. Use Global fields to simulate a log on and password system and actually use hidden(default) passwords to protect the files on the server. The server files could also be setup to not allow access except through the open file. You can also use the information to autofill some fields in the database. We use this process all the time and with some forethought and planning it can work very nicely and be relatively unobtrusive to your users.

[michaelzap]

AHA!!!

So that's why I can't open the file I was just sent! Instead of a regular password-protected file, it has one of these open scripts. There are several related files, including Setup and Codes, and I could see (but not change) in document preferences that it was trying a default password...

So now how do I go about entering the password they gave me? Or do I need to change my User Name to someone in an allowed Group? How can I change the default password that's being entered?

[aricm]

Thanks, that sounds like it might do the trick (without hindering the navigation system too much). Do you assign the default password in the open file and paste it upon opening another file? Since I will need the security the groups feature provides, do I map each user to a password that is the default for their group?

[DykstrL]

OK, let's see if I can explain the concept.

First, if a file requires a password to open, that same password will automatically be passed to any other files opened either with a script or manually. So to make this work, you need to set up the same password structure in each file: a master password for editing, etc.; then a secondary password that will be used, but invisible (default) to the user.

In the 'open' file, set up some global fields - this file will only have 1 record in it to store the globals. Let's say we are going to use a 'logon' and 'password' for the user - so create those fields as global, text. Setup the master and secondary passwords in the file, setting the secondary password to only allow editing of the records - you can also set Available commands to 'none'. In the document preferences, set the Try default password to the secondary password.

Create an Open Script:

Set Field(Logon,"")[These clear the fields]

Set Field(Password,"")

Go to Layout #1

Toggle Status Area (Hide),Locked

Create a Script:

Set Error Capture ON

Allow User Abort OFF [This keeps the users out of the scripts]

[This is where you would 'push' the logon and password data to the files you want to open]

Set Field (file1:logon,logon)

Set Field (file1 : password,password)

[Repeat this for all of the files you want to open using the logon and password info. This is not necessary for the related files.]

Perorm Script [external] file1,Open script

Close

Place the 2 fields on a layout.

Also create a button on the layout called 'Logon' and set it to run the above script. Yo can also create a 'Cancel' button that just closes the file [user cancel].

In 'file1' create the same 2 global fields(logn and password). You would set up a separate 'open script' based on the information in the globals, you can do finds and sorts, custom layouts, etc. in each open script. The main Open Script would look something like:

If(logon="Joe" AND password = "12345",

Perform Script[JoesOpen]

End If

[repeat for each logon and password]

[last default script steps]

Go to Layout[Access Denied]

Toggle Status Area[hide],locked

Beep

Halt Script

In file1, do not use 'Try default password' - let the open file pass the default password - this will require the user to use the open file to access the file(s).

To open the files using the master password, hold down the shift key while opening the file (Option key for MAC).

Hope I explained this so it is understandable.

[ March 26, 2001: Message edited by: dykstrl ]

[aricm]

First off, thanks for that thorough explanation. If I use that approach, it will be invaluable.

Not to beat a dead horse or anything, and your approach sounds like it will help, but I'm going to have to have a password and login for each user, and this requires a new navigation structure with an open script for each file that might be opened separately. Plus it adds the third interface for user management (since the administrator will have to manage the Filemaker password rights, the entry passwords for individual users, and the login security for the terminals), which I was hoping to avoid.

Isn't there any way to just access the data that would normally be inserted by the Created By auto-entry? I guess I could have a dummy field and copy the text from there, but that's kind of the long way around and it seems like we should have direct access to that data as a function. Last question on this topic, I promise!

[DykstrL]

If you're talking about the User Name in the application preferences, I would think that is going to give you the same problems. Think about this - if an employee leaves and his/her name is in the User Name block, you are going to have to physically visit that workstation to change it, or use some kind of remote access software.

The method I proposed could be centrally managed. You could group the users into maybe a dozen or so 'passwords' - which is probably what you would want to do if you used the FMP password system for each user [and to change passwords in FMP requires the file to be closed].

Yes, the Method I proposed would initially take a lot of planning and setup and some of the script routines could be quite long, but would allow you to:

1. manage and maintain the files centrally

2. make most changes without taking the files off line

3. make password changes effective instantly

Some more food for thought: instead of thinking about trapping for ALL users and instances, why not just trap the exceptions, i.e., users who may need to make approvals or maybe edit or delete records, would be trapped with a different set of passwords. Even think about giving just each office or division thier own passwords.

[ March 27, 2001: Message edited by: dykstrl ]