Security

It is up to you to decide if you want to require users to authenticate in to your mobile file on their iOS device. Many users will choose to use an auto-enter account and password so local users won't be asked to authenticate each time they open the mobile file. This makes more sense in syced files than others because a) the file often doesn't have any/much data in it, b) you can instruct users to secure the device with strong passwords, instead of securing the file, and c) the local file has no account information (no access) for the hosted files.

It is up to you to decide if you want to require users to authenticate in to your mobile file on their iOS device. Many users will chose to use an auto-enter account and password so local users won't be asked to authenticate each time they open the mobile file. This makes more sense in syced files than others because a) the file often doesn't have any/much data in it, b) you can instruct users to secure the device with strong passwords, instead of securing the file, and c) the local file has no account information (no access) for the hosted files.

And if you're concerned about theft of the mobile device, check out the Remote Wipe available here: http://www.apple.com/ipad/built-in-apps/find-my-ipad.html  Note that you can also turn off "simple passcodes" in your iPhone or iPad's settings to use longer, more secure device passwords.

'''Hosted Files.'''

'''Local files. (files on your iPhone or iPad)'''

Users will also be asked to authenticate each time they return to an open local file (such as after switching away to another ap, or after closing their iPad) unless you use the fmreauthenticate extended privilege to control when users will be required to reauthenticate after not using FileMaker Go for a specified period of time. You'll likely want to add this to the privilege set in effect on your iOS Devices.

-> Create an upon opening script in your file that uses Get ( ApplicationVersion ) to test if the user is on FMGo or FMPro. Run this script with Allow User Abort Off

When the remote file hits the GoZyncHosted, you should ask for the user to authenticate: this means you should add user accounts to GoZyncHosted (GZH). GZH, then sends its contents to the main solution either as part of a pull or round trip (in which case a user authenticates into your main solution) or as a script schedule, which is itself run under an authenticated account. (Learn more about [[AutoProcessing | automated processing]].)

Though each deployment will have to consider their unique security requirements, the following recommendations give, we believe the best user experience for working your local GoZync file.

-> The accounts users employ to open GZH don't need to be the same as those in your your main solution if all you're doing is ''pushing''. Though GZH will need at least one shared account... the one used by the server-side script [[AutoProcessing | processing your inbox automatically]]; if you're processing by hand, you'll simply be asked to authenticate into your solution when you process your first InBox record.

Users will also be asked to authenticate each time they return to an open local file (such as after switching away to another ap, or after closing their iPad) unless they enable the fmrestorelogin extended privilege. This is enabled in our Mobile.fp7 file by default for the [Full Access] privilege set.

You'll likely want to add this to the privilege set your users are using for the Mobile.fp7 file as well.

When it comes to your hosted files, your mobile file will actually connect to an intermediary file: GoZyncConnector (here is a [[MapOfZync | map]] of how all this work).

When the remote file hits the intermediary, you can choose to ask for the user to authenticate, but they only need to log into the intermediary file: your remote users don't need accounts in your master solution. The intermediary, GoZyncConnector, then sends its contents to the main solution either manually (in which case a user authenticates into your main solution) or as a script schedule, which is itself run under an authenticated account. (Learn more about [[AutoProcessing | automated processing]].)

If you choose to require authentication in GoZyncConnector, users will be asked to authenticate:

!! Our recommendations.

-> Secure the IOS device, but use an auto-enter account and password in the local file so users aren't asked to authenticate into it.

-> Make this account use a privilege set that doesn't allow access to layouts and scripts. For extra protection you can change the upon opening script to quit the solution if this "user" account is ever used to open the mobile file in Pro (as opposed to opening it in Go).

-> Require authentication into the intermediary file GoZyncConnector, but make these accounts and password different that those used to open your served solution. The accounts used to log into GoZyncConnector can be used to determine which mobile user is logging in, and prepare their own found set of data when [[pulling records down to go]].

-> Finally your intermediary file, GoZyncConnector, doesn't need any accounts that are shared with your main solution unless your mobile users are pulling data down from your hosted file (as we do getting price list items in our Mobile.fp7 example). You also need an account shared between GoZyncConnector and your solution if you're [[AutoProcessing | processing your inbox automatically]]; if you're processing by hand, you'll simply be asked to authenticate into your solution when you process your first InBox record.

For larger customers, Apple has a suite of Mobile Device Management (MDM) applications to help secure devices, push profile changes, pull applications and monitor password compliance. Learn more here: %newwin% http://www.apple.com/iphone/business/integration/mdm/

'''Local files.'''

It is up to you to decide if you want to require users to authenticate in to your mobile file on their iOS device. Many users will chose to use an auto-enter account and password so local users won't be asked to authenticate each time they open the mobile file. This makes more sense in GoZync files than others because a) the file often doesn't have any data in it, b) you can instruct users to secure the device with strong passwords, instead of securing the file, and c) the local file has no account information (no access) for the hosted files.

-> Finally your intermediary file, GoZyncConnector, doesn't need any accounts that are shared with your main solution unless your mobile users are pulling data down from your hosted file (as we do getting price list items in our Mobile.fp7 example). You also need an account shared between GoZyncConnector and your solution if you're [[AutoProcessing | processing your inbox automatically]]; if you're processing by hand, you'll simply be asked to authenticate into your solution when you process your first InBox record.

And if you're concerned about theft of the mobile device, check out the Remote Wipe available here: http://www.apple.com/ipad/built-in-apps/find-my-ipad.html

- Finally your intermediary file, GoZyncConnector, doesn't need any accounts that are shared with your main solution unless you're [[AutoProcessing | processing your inbox automatically]]; if you're processing by hand, you'll simply be asked to authenticate into your solution when you process your first InBox record.

It is up to you to decide if you want to require users to authenticate in to your mobile file on their iOS device. If you do choose to require authentication, you'll want to add the

> > privilege set stuff for preventing constant auth requests.

You can also use "file protection" (introduced in FileMaker 11) between the remote and intermediary files if you'd like, and/or between intermediary and the main solution.

When the remote file hits the intermediary, you can choose to ask for the user to authenticate, but they only need to log into the intermediary file: your remote users don't need accounts in your master solution. The intermediary, GoZyncConnector, then sends its contents to the main solution either manually (in which case a user authenticates into your main solution) or as a script schedule, which is itself run under an authenticated account. (Learn more about [[automated processing]].)

Several of the layouts in our sample mobile file are exposed in the layout menu. This is done to make it easier for developers to get in there and hook up the files to their solutions. When you deploy these files you'll want to make sure that only the solution specific layouts are exposed in the layout menu, hiding any layouts in the Under the Hood menu. Same goes for the GoZyncConnector file.