I've been working with FM since version 3. The standard way of keeping
users from doing dumb things such as pressing command + D to delete a
record, was to lock out the menu commands except for editing purposes.
All other functions were scripted with appropriate test performed in
the script.

The same thing can be done in FM7, however the user can easily bypass
this security.
Assuming I have 2 files;
Screens.fp7 and Data.fp7
each containing 2 passwords developer access and user access.
User access can create & delete records in all tables, can NOT modify
scripts nor layouts.

The "Screens" file opens with user access automatically and displays
data from the "Data" file.
When the user clicks the delete button, the script does its check then
deletes the record, no problem.

To bypass all this, the user would simply have to do the following:
- create a new FM file eg. "UsersNewFile.fp7" (where he has full
access)
- go to "Define File References"
- add a file reference to my "Data.fp7" file
- go to "Define Relationships"
- add a table occurrence selecting one of the tables in my "Data" file
(developer pwd is NOT asked for)
- create a new layout for the table reference which is actually a table
in my "Data" file
- in browse mode the user now has access to all menu commands for that
table, including "Delete ALL Records"

Aside from this, the user can create scipts in his file and simply link
them to my file since he can see a complete list of my scripts.

And if all that wasn't bad enough, if I haven't bound (created a
runtime and stripped out master access) the files he can get my field
calculation formulas using apple script which is where I used to store
validations for access codes.

ALL THIS can be done without ever knowing the master password to the
file.

How are other people getting around this problem?

In article <1124170062.942644.291290 (AT) g47g2000cwa (DOT) googlegroups.com>,
a (AT) pottnerconsulting (DOT) ca says...
Primarily because its not really security at all. Removing access to the
menus was just that... the menus were gone. You just told filemaker the
user wasn't supposed to be presented with Delete menus, not that the
user wasn't actually allowed to delete records.

There's your first mistake. If you don't want users deleting records,
deny them that priviledge. If your thinking: "But I want to let them do
it, but only if they run this special script I wrote... then its
ok...!!" Then see below.

Deja vu

Simple. RTFM

1) Deny the user access to actually delete records.
2) Write scripts in the file containing the restricted table to delete
the records, this file contains your validation.
3) Mark script as "Run with full access priviledges", and execute only.

RTFM to see exactly what #3 does.

Also read about priviledge sets, and extended priviledge sets.
Particularly the 'custom' options for record, script. You can prevent
user classes from executing individual scripts, accessing individual
fields, and so forth.

You can even define expressions to dictate under what circumstances a
user class can look at or delete a record.

And using #3 above you can write scripts, set to execute only, with
master priviledges enabled to give users a method of exceeding their
normal authority under tight controls.

Security, almost inherently, is a pain in the ass to manage. But it is
there if you need it and it is certainly doable.

AFAIK FM enforces the all defined security constraints for applescript
access.