Need to block status control area

[Charlie Pax]

I need to block (or better yet delete) the status control area (the little button in the bottom left of the screen that opens and closes the status area). Users who use this button will have the potential to seriously mess up my amazing solution. Can this be done? If so how? Thanks in advance for your assistance. I sincerely appreciate it. Using Filemaker Pro 8.5 Advanced.

Edited September 11, 2006 by Guest

[Fei]

Write an OPENING script which is executed upon opening your file. You can specify to lock it.

opening.zip

Edited September 11, 2006 by Guest
Attach File

[Charlie Pax]

Thank you so much...I've been using Filemaker since 1993 but I've never had a need to use that feature before. Best Wishes!

[Fei]

To be frank, you have to start with a new life in Filemaker 8 onwards. It change a lot ! A lots of the function which available in ver 6 and below have change to a new command/code. You will love ver 8 functions since it shorten your dev time and few times faster than the old Filemaker ver 6 and below.

Enjoy and have a nice day.

[Steven H. Blackwell]

Just remember that opening scripts can be bypassed. Set a script that hides and locks the status area. Call it as a subscript from the opening script, but also call it at other intervals and in unexpected places.

Steven

[T-Square]

Steven--

There you go again! Raising flags I never thought about. How does someone bypass an opening script?

David

[Steven H. Blackwell]

There are any number of ways to bypass opening scripts. That's why they must not be relied upon for security urposes. There are too many variants to discuss here.

The simple expedient of calling any other script in the file will bypass the opening script as but one example.

TSquare, I am specifically not picking on you, but most of the people in the FIleMaker community know next to nothing about security or about how FileMaker Pro and FileMaker Server actually work from the security standpoint. This can and does produce all sorts of issues and problems.

I wrote FileMaker Security: The Book as an effort to explain the many complex issues related to FileMaker security. I am not here to advertise that book; however, I do recommend it to anyone who wants to learn about FileMaker security.

Steven

[T-Square]

Steven--

I don't feel picked on at all! I was trying light-heartedly to acknowledge my ignorance and perhaps receive some enlightenment.

To be honest, though, it does seem that every time someone proposes a method to secure an FM database, it gets shot down by someone on the Forums. It would be nice if there were instead some positive suggestions on security (besides External Server Authorization, which is beyond the resources of many smaller developers and clients).

David

[Steven H. Blackwell]

To be honest, though, it does seem that every time someone proposes a method to secure an FM database it gets shot down by someone

That's because most of what gets proposed in the name of security not only here but everywhere else as well detracts from and diminishes security rather than enhances it.

There are resources including three white papers on the FMI web site as well as some external third party resources. And we are diligently working to produce more of them.

Good security is not easy; but it is a must, and it will become increasingly so.

Steven

[pjdodd]

It would be nice if there were instead some positive suggestions on security...

I agree. Unless I've missed it, this site lacks a basic list of what to do to secure databases. Sure there are tips here and there with some nice ideas but they are frequently looked down upon as laughably naive. Occasionally some are mixed with scare-mongering remarks of an unsubstantiated nature that reflect badly on the people making them. You know the kind: "There are evil bad people out there who can steal your database, brainwash your family, raze your home etc all because you didn't limit creation access on your fluffy-rabbit table. You should not eat or sleep until this is fixed." Pur-lease.

I thought the aim was to help developers not keep them in fear of the big bad hacker. The overall impression from security posts is that you are incapable of doing it yourself and should hand over your development to someone else to do it. Filemaker provides little practical suggestions as what to do. Their information and white papers are directed at some group other than developers. The lack of clarity is worrying but it has allowed a negativity and snobbery to appear with regards to security issues.

I've read very little that directly applies to my solution (standalone, single file). There is, in my opinion, over emphasis on IWP, Servers, Multi-file solutions and sharing databases which naturally complicate security matters. Besides the obvious (removing Full-Access account and so on) I've applied various tips and invented one or two of my own. But I'm still in the dark about security and I've been working on a project for 19 months now.

Where is the help for the single file, standalone developers like myself? You would have thought someone would a list of suggestions by now.

[Steven H. Blackwell]

I've read very little that directly applies to my solution (standalone, single file). There is, in my opinion, over emphasis on IWP, Servers, Multi-file solutions and sharing databases which naturally complicate security matters.

That's becasue these are the overwhelming bulk of where FMP isntallations are actually deployed. And far from complicating security, Filemaker Server enhances it. A standalone database is probably the most vulnerable configuration if anyone can get physical access to it, pretty much a given.

Contrary to your belief, the Tech Briefs were written expressly for developers and for IT professionals. I know this; I authored or co-authored a number of them. In addition there are other resources including a number of Tech Info articles and the PTFS III Training Manual. And, as I have said before, while I am not here to advertise, there is also FileMaker Security: The Book for reference.

So far as the standalone database is concerned, here are some specific suggestions that apply mostly to commercially distributed solutions:

1. Scripts should all be either executable only or no access.

2. Value Lists should all be either executable only or no access.

3. Remove the [Full Access] Account with the Developer Utility tool designed for that purpose.

4. If using Custom Menus, do not allow users to create new layouts or scripts or to modify exisitng layouts or scripts.

5. Use the built-in FileMaker Pro security system. The ersatz log-on systems almost certainly guarantee that your files can be hacked.

6. Turn off Export privileges unless you really need to export data.

Steven