Now look at an example FileMaker database and explore the most basic security features available to the database developer. When asked for the password, enter -masterpw-. You’ll be brought to the List View layout where you’ll see several records of the database with all the values visible. You are currently logged in with the master password, which means you have full access to this database. Now you’ll learn how to set up passwords.
Setting Up Passwords
Go to File > Access Privileges > Passwords. You’ll see the Define Passwords dialog, which looks as such:
On the left is a list of all passwords defined for this database (don’t ever leave this dialog up on your screen when you’re not at your computer). On the right are the privileges specified for the currently highlighted password (here, masterpw’s privileges are shown). At bottom are buttons used to create and modify passwords. Here’s what these buttons do:
Creates a new password. First you must enter the password into the box at lower left.
To change the characters of a password or the rights granted to an existing password, highlight the password, make any changes, then click this button.
When you leave Define Passwords after making any changes, you’ll be asked for the database’s master password as a security precaution.
Deletes the currently highlighted password forevermore. This action is not undoable.
Brings you to the Access Privileges dialog where you can define which access groups are associated with which passwords and which layouts and fields a particular access group has access to.
Brings you to the Define Groups dialog where you can define all of your access groups. You’ll later associate these with certain passwords, which can then be restricted access to only certain layouts and fields.
Exits the Define Passwords dialog. Now take a look at the privileges you can grant or disallow to any given password in each database.(Each database in your database system can have different passwords and privileges.)
Access the Entire File
Check this box only for the master password(s) to a database. This privilege grants a user full access to administer passwords, define fields, and other toplevel access.
The user can flip through records in the database, viewing data within a record’s fields. If you can’t browse, you can’t edit either. The drop-down box to the right of this checkbox gives you the ability to add record-level security (or give access to all records by selecting “All”), meaning a user can browse records based on some kind of dynamic calculation scheme. (More on record-level security in the next section.)
The user can not only flip through records in the database, viewing data within a record’s fields, but can also change data in records. The drop-down box to the right of this checkbox lets you add record-level security, so that a user can edit only certain records based on some kind of dynamic calculation scheme.
The user can delete records from the database. Again, you can add record-level security, too, allowing users to delete only certain records (maybe records only with a certain status, or only that user’s records, or records with no line items). Be careful not to give users access to delete records if they aren’t allowed to browse records (or they could delete records they could not otherwise see or browse).
The user can add new records to the database. If you don’t have editing access also, once you close the database, you won’t be able to edit records, even if you created them in the first place.
The user can bring up a print dialog and send database layouts to the user’s printer of choice (including PDF or fax drivers, too).
The user can extract data from a FileMaker Pro database for use elsewhere. Records can be exported in many formats including comma-delimited, HTML tables, XML files, and others. Also, if unchecked, the user can’t share the database with other systems via ODBC, XML, Apple Events, or other external systems. Also, the user won’t be able to copy the found set to the clipboard or publish the database via the Web Companion plug-in. This is a powerful privilege; allow users this right only when truly necessary.
Override Data Entry Warnings
The user can ignore warnings like “are you sure you want to enter a date into this number field?” and enter invalid data into a field. Otherwise, all data entered into the database’s fields must follow the fields’ validation settings with no exceptions.
The user can access Layout mode.
The user can access ScriptMaker where they can add, modify, or delete scripts.
Define Value Lists
The user can define or modify value lists, available at File > Define Value Lists. Note that even if this is unchecked, users can still edit a value list connected to a field where the “Include ‘Edit’” checkbox is checked in that field’s format settings.
The user can change the password to the shared database he or she is logged in with. To change your password, choose Change Password from the File menu and change the password to the current database only using the dialog that comes up. (Usually you don’t grant users access to change database passwords like this.)
Available Menu Commands
Here you can choose which commands will be available under FileMaker’s menus at the top of the application. The choices are:
All menu commands are available, minus the ones like Define Fields, which you only get if the “Access the entire file” privilege box is checked.
The user will only get menu commands having to do with editing data in Browse mode, such as Cut, Copy, and Paste, and the commands available under the Format menu. Even most of the Records menu is grayed out. If you want users to be able to create records, you’ll have to create a button referencing a script with that functionality.
Basically none of the menu commands are available. Everything you want a user to be able to do must happen via buttons attached to scripts.
Disconnect from FileMaker Server When Idle
If the user is idle in the database for a period specified within the FileMaker Server software hosting the database, they are kicked out of the database, with a warning first. Keep in mind that the more idle users there are connected to the server the slower the database will run. (There are other notes about this checkbox that you should read in FileMaker Pro’s built-in help system.)
General Password Notes
Here are some other things to note about passwords:
Otherwise, the user will be asked for a password to the related atabase before accessing it. Try logging in to the PasswordsExample.fp5 database after changing some of the passwords’ privileges (some are already different for you) to see how your rights in the database change. (Remember not to alter the master password(s) without recording it so that you aren’t locked out forever.)
Log in to PasswordsExample.fp5 again, this time using the -A1000002- password.
You’ll see the list view:
As you can see, you only have access to about one half of the records. In fact, you only have access to browse, edit, or delete records based on a calculation (the calc specifies that this password only has access to records where the DollarAmount fields is less than $500.00). Try to click in or do anything to the <No Access> records. You can’t! You’ll get errors. You can edit, create, or delete the other, visible records, though, without problems.
This password has record-level security associated with it. Open the database again with masterpw and highlight the -A1000002- password in the Define Passwords dialog. Now select Limited from the drop-down next to Edit Records (the calc in all three of these is the same in this example, but could be different).
You’ll get the calculation window, where you can specify which records this password can access. Any record that “passes” the calculation (is true or meets the criteria), will be accessible for editing (or deleting or browsing); all others will show up, but will have “No Access” in any field on the screen for the inaccessible records.
Record-level security is one of the “killer app” features of FileMaker Pro, and adds a lot of possibilities to your databases. Using record level security you could:
Record level security takes a little bit of time to set up, but there are many ways to use it, especially in a security-heavy environment.
Setting Up Groups
Log in to PasswordsExample.fp5, again with masterpw. Go to File > Access Privileges > Groups. You’ll see this dialog:
Here you can set up access groups, which give you yet another way to organize and control how a user can access what’s in a database. Groups can be associated with only certain passwords and have specific layouts or even specific fields restricted from their view upon login.
To create a group, simply enter its name and click Create. You can also rename and delete groups (the latter of which is not undoable). To specify the access privileges of a group, highlight the group and click Access. You’ll get the dialog described in the next section.
Setting Up Access Privileges
The Access Privileges dialog looks like this:
This is where you specify which passwords, layouts, and fields will work or be accessible from which access groups.
This dialog works as follows. First, click the group name Alpha. The items with black dots to the left of them are accessible in this group (i.e., when you log in with one of these passwords, you’re at least part of this group). Also note that the layouts and fields that this group can see either as read only or with write access (see the legend at the bottom of the dialog) are also noted with dots.
To add passwords to a group, simply highlight it then click the dot next to the password that you want to add to the group. Do the same to remove a password from a group.
To change a layout or field’s accessibility for a group, highlight the desired group and then click the dot to the left of the layout or field that you want to modify. (Click several times to cycle through the “Not accessible”, “Accessible”, and “Read Only” settings for each layout or field.)
That’s it. Now when someone logs in with this password, inaccessible layouts will show as gray with the words “access denied” written across them; inaccessible fields will appear with “<No Access>“ inside them on an otherwise visible, unchanged layout; and “Read only” layouts and fields appear normal or accessible to a user but will give an error if the user tries to edit the data in them.
To see how these different settings work together, highlight the Alpha and Bravo groups and see how the privileges are set up as far as access to certain layouts and fields. Try logging in with any of the Alpha or Bravo group passwords, too (like -A1000001- or -B1000001-, respectively)to see how not having these privileges affect a user’s view into a database.
Layout/Field Inaccessibility’s Effect on Your Database’s Functionality
Remember that if the group a user is logged in with does not have access to a field or layout (read or write), then any script that tries to take action on that field or layout won’t work and could affect the integrity of your layout. For instance, try logging into Passwords Example.fp5 with the -B1000001- password and run the “Copy Dollar Amount” script to see the error you’ll get.
File Maker Related Interview Questions
|Management Information systems Interview Questions||Software Engineering Interview Questions|
|File net Interview Questions||Data analyst Interview Questions|
|Hadoop Distributed File System (HDFS) Interview Questions||Linux File Systems Interview Questions|
|Excel Data Analysis Interview Questions||Asp Dot Net Database Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.