Setting per-user access privileges for shared database

[elipsett]

I thought I understood this reasonably well, but it seems not.

Until recently we were running FM Server 9 on a Mac Mini, but when the Mac Mini died we were forced to switch to a fileserver running OSX10.7, which meant we needed a new version of Server. That costs a lot of bucks. I am trying to handle it with only regular FMP11 apps instead.

Here's the current set-up:

I have about half a dozen machines all running FMP 11.

The fileserver is running FMP11. It has a couple dozen databases (DBs), many referencing each other, and makes them available on the office network to the other FMP11 apps.

I open all the databases on the fileserver with a username/password for full access.

A user copy of FMP11 (different serial number, different user name) opens up that DB remotely.

Each DB has 2-3 privilege sets.

I have been unable to figure out any way of controlling access privileges.

I hope this is a dumb question with an obvious solution.

Thank you for your time.

Edward Lipsett

kurodahan.com

[elipsett]

More information:

Yes, I could have each user enter account/password each time they open a DB, but for each DB opened explicitly, there are a few more opened invisibly via relationships. It would be possible to force each user to do this for each DB, but would take a long time. And they would all hate me for it.

It would be far better if they could just open the file with a single script or Open command, and automatically have the correct privileges applied.

[Vaughan]

If a user has an account and password set up the same in each file, they will only be prompted to authenticate ONCE, and all related files with the same u+p will open silently.

[elipsett]

OK, that's clearly a step in the right direction, thank you.

That also means that when I turn all the FMP files on every Monday morning (or whenever), I have to login manually instead of merely setting each to open automatically with a given account.

So, two questions, if you have a minute:

1. Is there any way to programmatically a file with a specified account and password? That would make it possible for me to just give each client a set of buttons with scripts attached.

2. If not, then would it be possible to make a single "menu" database that is linked to every file that might be needed? When the user opens that menu using his account, that account should be automatically used to open all the linked databases, which should resolve this problem. Which in turn suggests that I can set the menu database to open automatically with the account name and password I want them to use. Or am I heading for disaster here?

I should point out that I'm not worried about people looking at data they're not supposed to see.

I just need to stop people from accidentally changing data they're not supposed to change.

Thanks.

[Vaughan]

All of the above is possible, but you need to think about this:

Why have passwords and security, then not require uses to use them to log-in. If it was a house, you've got locks on the doors but leave them open.

Also, I'm concerned by your comment "when I turn all the FMP files on every Monday morning". My recommendation is to set up a dedicated host for the databases running FM Server or (less good) a copy of FMP.

"I should point out that I'm not worried about people looking at data they're not supposed to see."

Until somebody walks out with the organisation's entire client list on a USB stick.

[elipsett]

Can you point me to the scripting that allows me to open a remote file with a specific account and password?

The database is on a dedicated server. As I explained in my first message, we do not have FM Server now, because of the cost... we only have four people using the databases at all.

I generally dump the office power every Friday night, for several reasons.

I'm not worried about people looking at data they're not supposed to see because there ISN'T any data they aren't supposed to look at.

One of the advantages of being in a very small company. There aren't any secrets, and yes, if someone wanted to walk out of here with the entire client list I couldn't stop them. I guess it's a lucky thing we're partners, then.

[Vaughan]

Just get FM Server. Take advantage of FMI's annual license which is very cheap and it all comes off the tax at the end of the year.

Compare that cost to the amount of mucking around you're doing now.

[comment]

That also means that when I turn all the FMP files on every Monday morning (or whenever), I have to login manually instead of merely setting each to open automatically with a given account.

I don't see why this should be necessary. I believe that as long as the files are opened by the host, it doesn't matter which account opened them. Users (i.e. clients) have to log in on their own - but as Vaughan said, If their account and password exist in each file, they only need to do this once. In fact, it should work exactly like it did before, when you had a server - unless you used external authentication.

You could also provide each client station with an "opener file" to log into the hosted file/s automatically - but then you only know which computer was used, not by whom.

The fileserver is running FMP11. It has a couple dozen databases (DBs), many referencing each other, and makes them available on the office network to the other FMP11 apps.

Hopefully, that part is not true.

Edited November 15, 2011 by comment

[Steven H. Blackwell]

The fileserver is running FMP11. It has a couple dozen databases (DBs), many referencing each other, and makes them available on the office network to the other FMP11 apps.

Mr. Lipsett:

THis is a bad idea; and you are flirting with damage to your files and their data by doing this.

Do follow the advice you've been given in this thread and invest in FIleMaker Server.

Steven

[Vaughan]

I have a client in a large educational institution whose IT refuses to support FileMaker. COnsequently they store the files on a shared network volume. One person opes the file in FMP an becomes the "host" which other people then connect to. There are only 2 users and they have been doing this for years and it's been no problem yada yada yada.

One user -- the boss, my client -- always likes double-clicking the files on the file share instead of opening FMP and going through open remote.

Recently I've gone in and done $20,000 worth of development to the databases, so they are now out of the "hobby" stage and need to be considered serious business systems. Twice in a month the file has had its OS-level privileges damaged because it's been double-clicked on when already open. It then takes 2-3 days for IT support to get around to fixing it (because it requires admin access).

This makes FMP look fragile and unreliable, but it's not FMP's fault, it's the OS doing nasty things at the file level. It is only a matter of time until the damage becomes great enough to cause big problems and result in data loss.

Hosting the files in FMS will solve all that and improve performance too. I need to convince their IT that the world won't end if they have a copy on their network.

[comment]

One user -- the boss, my client -- always likes double-clicking the files on the file share instead of opening FMP and going through open remote.

I must be missing something here: what does this have to do with the files being hosted by FMS or by FMP? Couldn't you simply place the files in a non-shared directory?

[Vaughan]

I must be missing something here: what does this have to do with the files being hosted by FMS or by FMP? Couldn't you simply place the files in a non-shared directory?

The first user has to be able to see the files to open them.

It's worst-case-scenario all round.

[comment]

The first user has to be able to see the files to open them.

True. And if the files are accessible only locally, the first user MUST be on that computer. Which is what the OP wants and does anyway.

Otherwise you'd be saying that the option to host by FMP is not. But that's not what FMI are saying.

Edited November 15, 2011 by comment

[Vaughan]

Indeed, hosting local files with FMP is not worst case scenario.

Edward: see if FMI have an upgrade option. FMS is an exceptionally good product and it does more than save you typing usernames and passwords on startup.

[elipsett]

The files are located on the file server, which does only two things. It runs the FMP databases (turned on Monday morning, basically, and off Friday night), and it serves as a shared file depository for OSX and Windows machines. Nobody uses the FMP files on that machine. All users access it via the office network. The file server is firewalled from the Internet completely, and only allows 192.168 local Ethernet access.

I used FMS9 for many years and was quite happy with it. I have been trying out the methods discussed above and they work fine for our needs, and our (essentially non-existent) security requirements.

Given that, the cost of FMS is unacceptably high. If it were impossible or unduly complex to do what I need with FMP11 I might be forced to consider FMS, but as it turns out it is not needed for our particular situation.

Thank you all for providing clarification of how accounts and passwords work in FMP11. My problem has been resolved.

[comment]

It runs the FMP databases (turned on Monday morning, basically, and off Friday night), and it serves as a shared file depository

Just make sure the FMP databases are NOT part of the shared file depository.

[Steven H. Blackwell]

Since later in the coming calendar year FileMaker version 9 will no longer be supported and will be officially EOL, you may want to take advantage of upgrade opportunities and pricing now.

Steven