GoZync4

Security

GoZync4.Security History

Hide minor edits - Show changes to output

July 01, 2013, at 06:59 PM by 24.22.243.133 -
July 01, 2013, at 06:58 PM by 24.22.243.133 -
Changed lines 51-64 from:
to:
You'll find this "Sync" privilege set in GoZyncMobile as well so if you log GoZyncMobile in using "Sync" in your Upon Opening script AND GoZyncMobile and GoZyncHosted have the same account name and password for the "Sync" privilege set, you can turn off the File Options account in GoZyncHosted. That is idea.

So in this ideal setup it would look like this:

-> GoZyncMobile (GZM) uses logs into the Sync privilege set via your Upon Opening script when it is opened on iOS.

-> GZM shares this "Sync" account name and password with GoZyncHosted (GZH) and passes these credentials up to GZH during sync, opening it under "Sync" as well. (You don't have to do anything about this "passing credentials" that is just how FileMaker opens files.)

-> If GZH is opened by something other than GZM, users will be asked to log in.

-> If GZM is opened off of an iOS device, users will be asked to log in.

-> ALL users will be asked to log in to your hosted files at the beginning of the sync.

July 01, 2013, at 06:52 PM by 24.22.243.133 -
Changed lines 3-4 from:
'!! Authentication (Files on your iPhone or iPad)
to:
!! Authentication (Files on your iPhone or iPad)
July 01, 2013, at 06:52 PM by 24.22.243.133 -
Changed lines 1-4 from:
!! Authentication

'''
Local files (Files on your iPhone or iPad)'''
to:
! Local Files

'!! Authentication (Files on your iPhone or
iPad)
Changed lines 33-34 from:
'''Hosted Files'''
to:
! Hosted Files
June 30, 2013, at 05:54 PM by 50.132.84.245 -
June 30, 2013, at 05:54 PM by 50.132.84.245 -
Changed lines 49-50 from:
Then, when you need to log in as an admin user, run the "Relogin" script from GoZyncHosted and enter your Admin account and password. (You likely want to switch this from Admin / blank which is the FileMaker default for admin accounts and a bit easy to guess.)
to:
Then, when you need to log in as an admin user, run the "Relogin" script from GoZyncHosted and enter your Admin account and password.


!! Changing default Full Access accounts

You'll likely want to switch the default Full Access account fro both GZM
and GZH from Admin / blank which is the FileMaker default for admin accounts and a bit easy to guess.
June 30, 2013, at 05:46 PM by 50.132.84.245 -
Changed lines 47-48 from:
%center% %width=500px% http://www.seedcode.com/rootimages/pmwiki/gozync/syncprivset.png
to:
%center% %width=500px% http://www.seedcode.com/rootimages/stikipad/gozync/syncprivset.png
June 30, 2013, at 05:46 PM by 50.132.84.245 -
Changed lines 43-44 from:
GoZyncHosted doesn't have any file references to your hosted solution (your "mothership" files) but it does contain your configuration instructions, so you don't want just any user messing around in there. We've created two privilege sets in GoZyncHosted: "Admin" and "Sync". Admin is a full access privilege set and "Sync" is a lower level access that lets users sync but not change the sync settings. We recommend you default GoZyncHosted to the sync privilege set, and then log in as an admin user when you want to make changes to the sync settings
to:
GoZyncHosted doesn't have any file references to your hosted solution (your "mothership" files) but it does contain your configuration instructions, so you don't want just any user messing around in there. We've created two privilege sets in GoZyncHosted: "Admin" and "Sync". Admin is a full access privilege set and "Sync" is a lower level access that lets users sync but not change the sync settings. We recommend you default GoZyncHosted to the sync privilege set, and then log in as an admin user when you want to make changes to the sync settings.

To do this, open GoZyncHosted and select File Options from FileMaker's File menu. The under the "Open" tab, enter the default Account and Password for the "Sync" privilege set: both of which are "Sync":

%center% %width=500px% http://www.seedcode.com/rootimages/pmwiki/gozync/syncprivset.png

Then, when you need to log in as an admin user, run the "Relogin" script from GoZyncHosted and enter your Admin account and password. (You likely want to switch this from Admin / blank which is the FileMaker default for admin accounts and a bit easy to guess.)

June 30, 2013, at 04:24 AM by 50.132.84.245 -
Changed lines 39-40 from:
You really don't need to secure your files any differently than you do now: syncing users will be asked to authenticate
to:
You really don't need to secure your files any differently than you do now: syncing users will be asked to authenticate when they sync begins and if their login fails the sync will abort.
Changed lines 43-45 from:
GoZyncHosted doesn't have any file references to your hosted solution (your "mothership" files) but it does contain your configuration instructions, so you don't want just any user messing around in there. We've created two privilege sets in GoZyncHosted: "Admin" and "Sync". Admin is a full access privilege set and "Sync" is a lower level access that lets users sync but not change the sync settings. We recommend you default GoZyncHosted to the sync privilege set, and then log in as an admin user when you want to make changes to the sync settings.

to:
GoZyncHosted doesn't have any file references to your hosted solution (your "mothership" files) but it does contain your configuration instructions, so you don't want just any user messing around in there. We've created two privilege sets in GoZyncHosted: "Admin" and "Sync". Admin is a full access privilege set and "Sync" is a lower level access that lets users sync but not change the sync settings. We recommend you default GoZyncHosted to the sync privilege set, and then log in as an admin user when you want to make changes to the sync settings
June 30, 2013, at 04:22 AM by 50.132.84.245 -
Changed lines 9-11 from:
If you do choose to require authentication in the local file, users will be asked to authenticate when they:

-> Open
the file.
to:
If you do choose to require authentication in the local file, users will be asked to authenticate each time they open the file. If you're breaking connections to the served files often, users will also be asked to log in...
Changed lines 19-20 from:
So here are our recommendations for securing your mobile files (you do this to GoZyncMobile as well if you wish).
to:
So here are our recommendations for securing your mobile files (you can do this to GoZyncMobile as well if you wish).
Changed lines 29-30 from:
-> 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. See %newwin% [[http://www.filemaker.com/support/product/docs/12/filemaker-go/fmgo_development.pdf | FileMaker's Go Development Guide]] for more details.
to:
-> 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. The number after fmreauthenticate indicates how long, in minutes, the user can go inactive without having to reauthenticate: fmreauthenticate0 means they would have to reauthenticate every time they come back; fmreauthenticate120 would let them stay away 2 hours before they'd have to log in again. See %newwin% [[http://www.filemaker.com/support/product/docs/12/filemaker-go/fmgo_development.pdf | FileMaker's Go Development Guide]] for more details.
Changed lines 35-46 from:
When it comes to your hosted files, your mobile file will actually first connect to an intermediary file: GoZyncHosted (here is a [[MapOfZync | map]] of how all this work). When "[[ZyncOptions | pushing]]" this is the only file that opens. When "pulling" or "round-tripping", both GoZyncHosted and your mothership file are opened.

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]].)

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

-> Before downloading a new version of the mobile file.
-> Before downloading new data from the server.
-> and Before sending data to the server.

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.

to:
When it comes to your hosted files, GoZyncMobile will open your hosted solution (your "[[glossary | mothership]]" files) at the beginning of a sync session. This is when users will be asked to log into your solution.

!! Our Recommendations: Your Hosted Files

You really don't need to secure
your files any differently than you do now: syncing users will be asked to authenticate
Changed lines 43-50 from:
Though each deployment will have to consider their unique security requirements, the following recommendations offer the best user experience for working your local GoZync file.

-> Require authentication into the intermediary file, GoZyncHosted (GZH).

-> 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.

-> In most cases, however, you'll be pushing, pulling, and round-tripping, so the accounts created in GZH should be the same as those used in your mothership solution. This will also enable you to know *who* is syncing so you can use GoZync's scripts to [[DownloadingFoundSets | filter records being pulled down]].

to:
GoZyncHosted doesn't have any file references to your hosted solution (your "mothership" files) but it does contain your configuration instructions, so you don't want just any user messing around in there. We've created two privilege sets in GoZyncHosted: "Admin" and "Sync". Admin is a full access privilege set and "Sync" is a lower level access that lets users sync but not change the sync settings. We recommend you default GoZyncHosted to the sync privilege set, and then log in as an admin user when you want to make changes to the sync settings.

June 30, 2013, at 12:51 AM by 50.132.84.245 -
Deleted lines 0-6:
Get Account name for filtering found sets: two methods

1. Make a simple script in your hosted file that returns account name as a script result. (create example in QuickContactHosted).

2. Create accounts and passwords in GZM to match your hosted files.

June 26, 2013, at 08:41 PM by 108.38.141.66 -
Added lines 1-7:
Get Account name for filtering found sets: two methods

1. Make a simple script in your hosted file that returns account name as a script result. (create example in QuickContactHosted).

2. Create accounts and passwords in GZM to match your hosted files.

May 21, 2013, at 04:22 PM by 67.190.87.90 -
Changed lines 5-6 from:
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.
to:
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 synced 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.
May 21, 2013, at 04:22 PM by 67.190.87.90 -
Changed lines 5-6 from:
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.
to:
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.
Changed lines 7-8 from:
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.
to:
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.
Changed lines 34-35 from:
'''Hosted Files.'''
to:
'''Hosted Files'''
Changed lines 3-4 from:
'''Local files. (files on your iPhone or iPad)'''
to:
'''Local files (Files on your iPhone or iPad)'''
December 10, 2012, at 10:53 PM by cm - minor edits and clarifications
Changed lines 16-17 from:
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.
to:
Users will also be asked to authenticate each time they return to an open local file (such as after switching away to another app, 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.
Changed lines 24-25 from:
-> 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
to:
-> 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.
Changed lines 38-39 from:
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]].)
to:
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]].)
Changed lines 50-51 from:
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.
to:
Though each deployment will have to consider their unique security requirements, the following recommendations offer the best user experience for working your local GoZync file.
Changed lines 54-55 from:
-> 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.
to:
-> 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.
November 02, 2012, at 05:20 PM by 50.132.84.245 -
Changed lines 16-19 from:
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
.
to:
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.

!! Our Recommendations: Your Mobile Files

So here are our recommendations for securing your mobile files (you do this to GoZyncMobile as well if you wish).

-> Secure your iOS device with a passcode.

-> 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

-> If they are on Pro, call the relogin script step with NO options so they need an account to use the file.

-> If they are on Go, call the relogin script step using an account that lets them do their work but is NOT shared with the hosted solution.

-> 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. See %newwin% [[http://www.filemaker.com/support/product/docs/12/filemaker-go/fmgo_development.pdf | FileMaker's Go Development Guide]] for more details.

-> When users go to sync they will be asked to log in to GoZyncHosted, and will then do so using an accounts shared with the hosted files... (see the next section)

Changed lines 36-41 from:
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:
to:
When it comes to your hosted files, your mobile file will actually first connect to an intermediary file: GoZyncHosted (here is a [[MapOfZync | map]] of how all this work). When "[[ZyncOptions | pushing]]" this is the only file that opens. When "pulling" or "round-tripping", both GoZyncHosted and your mothership file are opened.

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]].)

If you choose to require authentication in GoZyncHosted
, users will be asked to authenticate:
Changed lines 48-49 from:
!! Our recommendations.
to:
!! Our Recommendations: GoZyncHosted
Changed lines 52-59 from:
-> 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
.
to:
-> Require authentication into the intermediary file, GoZyncHosted (GZH).

-> 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.

-> In most cases, however, you'll be pushing, pulling, and round-tripping, so the accounts created in GZH should be the same as those used in your mothership solution. This will also enable you to know *who* is syncing so you can use GoZync's scripts to
[[DownloadingFoundSets | filter records being pulled down]].
Changed line 60 from:
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/
to:
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. This can help more thoroughly secure your iOS devices. Learn more here: %newwin% http://www.apple.com/iphone/business/integration/mdm/
November 02, 2012, at 04:52 PM by 50.132.84.245 -
Deleted lines 0-3:
!! Layouts

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.

Changed lines 3-6 from:
'''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.
to:
'''Local files. (files on your iPhone or iPad)'''

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.
June 27, 2011, at 03:49 PM by 76.22.74.86 -
Changed lines 48-52 from:
-> 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.
to:
-> 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.

!! Enterprise customers: MDM

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/
June 27, 2011, at 03:47 PM by 76.22.74.86 -
Changed lines 11-12 from:
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
to:
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.
June 16, 2011, at 07:06 PM by 75.196.57.43 -
Added lines 11-12:
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
June 03, 2011, at 01:38 AM by 76.22.74.86 -
Changed line 46 from:
- 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.
to:
-> 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.
June 03, 2011, at 12:58 AM by 76.22.74.86 -
Changed lines 7-10 from:
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
.
to:
'''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.

If you do choose to require authentication in the local file, users will be asked to authenticate when they:

-> Open the file.
-> After downloading new data from the server.
-> After downloading a new version of the mobile file.
-> and After sending a batch of records to the server.

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.

'''Hosted Files.'''

Added lines 28-33:
If you choose to require authentication in GoZyncConnector, users will be asked to authenticate:

-> Before downloading a new version of the mobile file.
-> Before downloading new data from the server.
-> and Before sending data to the server.

Added lines 35-46:

!! Our recommendations.

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.

-> 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 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.
May 17, 2011, at 05:14 AM by 76.22.74.86 -
Changed line 15 from:
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.
to:
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.
May 17, 2011, at 05:13 AM by 76.22.74.86 -
Changed lines 13-14 from:
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]].)
to:
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]].)
May 17, 2011, at 05:13 AM by 76.22.74.86 -
Changed lines 3-15 from:
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.
to:
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.

!! Authentication

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.

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 [[automated processing]].)

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
.
May 17, 2011, at 05:08 AM by 76.22.74.86 -
May 17, 2011, at 05:08 AM by 76.22.74.86 -
Added lines 1-3:
!! Layouts

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.
(855) SEEDCODE
support@seedcode.com
Follow us: