It would help if you described the file structure. I think you are saying that iPad users are logging directly onto a hosted file, and the credentials in question are for that file, but I am not sure. When you say 'public', do you mean anyone can use these devices? They are in something like a library or other institution, where the specific identity of the user is not part of the login credentials? How are credentials being validated on the server?
In any event, the most likely culprit is the fmreauthenticatexx extended privilege setting.
You might also take a look at Katherine Russell's very useful guide to sync, at http://www.filemaker.com/solutions/ios/docs/fmi_guide_sync_en.pdf. Note on pages 11-12 and18-19 she reviews how Go handles various conditions of wakefulness.
When FileMaker Go goes into hibernation mode, whoever is logged in is the only person who can reauthenticate and return to the original state it was in. Quitting and logging in is the only solution if the original credentials are no longer available. This behavior happens this way because if someone else could log in from hibernation, they would end up in the state you were previously in. If someone else could use their credentials to wake you from hiberanation, then they would be bypassing things like the startup script to end up where you were at in the solution. This situation you describe follows FileMaker security guidelines.
Like Datagrace was telling you about, you can change the Extended Privileges to allow longer periods of hiberanation without having to log back in, but that just means it is easier for someone to open it up and use it under the former users's account easily. Maybe that minor security risk is acceptable, maybe not.
PS: Maybe in the future FileMaker can give an option to log out and log back in without quitting.
This makes sense in general. If a user that has access to certain layouts or records lets thier session time out the next user may not have the same level of access and that could be a problem.
These are public in the sense that there is one iPad for the shipping department with 3 employees that use it. I could set a generic shipping user, but that does not help us track which users make data entry errors. All of the general users basically have the same access level so there is no security risk, but still no way to track individual activity.
Is there a need to quit the file or quit the app? I am really trying to make this user friendly. When the users think Filemaker is broken itis bad. Thank you for the direction. I will keep working on a way to make this smoother. One answer is to buy everyone their own iPad, not really feeling that though.
Have you considered, creating a global field were the user selects their name. Then use that field to keep track of the individual activity. You could also require the user to enter a password into a field to validate who they are.
It sounds like you are dealing with two issues-- security and identifying the user. For security, is there any reason to not set up the login as automatic, so long as the privilege level is low enough to ensure safety? This would work around the authentication/hibernation problem. Admin users could still force a prompt for credentials.
To identify the user, what RGordon describes can get you started. You can build on that by setting up a Users table of personnel, which can populate a pulldown list from which they select their name as part of a login routine (filter out inactive users). You can go a little further by posting login/logout timestamps to a Login table. A $$Var can be set on login to hold the user's ID, and that value can be applied to any record creation, and mods where you need to track them. A further refinement would be an audit log of record changes. None of this is very difficult to build, and should not add noticeable overhead.
Considering it now.
What do you mean by setting the login to be automatic.
I am considering to have department ID and password with some sort of modal message to collect user ID and password that feeds record changes to a table or a field on each record for user tracking.
Security is only needed that the solution cannot be open to guest logins. This is a lot less about security and more about error tracking.
Now that I understand what is happening I can make smoehting work. I guess I expected FMGo to run the startup after sleeping/wake. Cant I just force the app tp close the file and the app before sleeping. This would force a relaunch on fresh credentials.
File login can be set in File/File Options/Open to automatically open with a specific set of credentials.
As for forcing the app to close itself, the 'Exit Application' script step does not actually do so in Go. Closing the last open file is the next best thing, but it leaves the user in the Go area-- most likely 'Recent Files'-- rather than on the Home screen. Under certain circumstances, they may be unable to re-connect to the host until after briefly going Home and coming back. If your users do not run into this problem and they can easily navigate back to the correct file from the Go area, then you should be fine. If things do not run smoothly, you might consider building a button on the Home page to open the file. For that you'd want the Apple provisioner tool, or Eric Jacobson's Go App Maker, which simplifies that task.
I tried exit application and it did not work. Sometimes simply closing the file requires forcing the app to close and reopening to login to the file again.
I have an icon on the home screen. Made it with the Go App Maker. Never worked right. Always asks permission to open the file instead of just opening the file. I am working on redoing the iPad launch to determine if the connection is on the office wifi or other so it will open the local file or remote file depending on connection. Because the users should have just one button right. I might just send the login credentials with the icon and extend the reconnect time.
Get Filemaker Server with Filemaker Go and quickly and easily get your database running on iPads, they said.....haha yeah right. Definitely not the PnP interface FM advertises, but still very much worth the time and money.