1 of 1 people found this helpful
Not sure I understand you Wolfgang,
1) Are you looking to allow a user to only ever log in one time (single login, then no access)?
2) Only allowing a single account to be logged in "live" (IE, two users can not log in with the same credentials at the same time).
The answer to both is yes, and both could be accomplished in a few different ways.
1) Reference the "delete account" script step:
2) For this you will need to:
-create an "open logins" table that has a field for storing Get(AccountName).
-add to an "on first window open" script two things:
-check the open logins table to see if there is already a record for Get(AccountName) and closes file if
there is a user logged in.
-If they were not disconnected, write a record to the open logins table with Get(AccountName)
-add a "on last window close" script that deletes the matching Get(AccountName) record when a user exits.
There are some caveats to this solution, while the above is a basic understanding, you would want to make it more robust to avoid collisions, and test for when the database was forcefully disconnected (IE open logins table was never cleared when a user logged out). It might help to set user time out on your server, and also have a script that clears that table every night run from the server.
Hopefully this helps, if either of these was not what you were looking for, please explain in more detail.
1 of 1 people found this helpful
I have been trying to wrap my head around this problem since it was asked earlier today. I obstained from comment earlier because I did not think that there was a robust way to accomplish what he wants (as I read it, the second option, prohibiting more than one simultaneous connection).
Mike B's idea would approximate a solution, but as he stated, it would not handle disconnects gracefully and ultimately require administrator intervention to reset an account if the "open logins" table got out of sync. A server-side script to clear the table out would potentially allow a user to leave their connection up overnight and open a second instance the next morning. I can think of a few ways to trick such an implementation as well. I guess that it really depends on how important limiting multiples logins actually is in this case. Mike B's implementation would allow the admin to check the console and only clean out the "open logins" table if the user was acutually disconnected.
What would be really useful would be a function that would return all users currently logged in (just like FM Server's admin console provides) that one could compare Get (AccountName) with this result upon login. I cannot envision a good way to scrape this data from the Java app that is the Admin Console.
just a thought; what about using a global variable, instead of the logins table, with the startup script set to run with full access privileges?
Can't test as do not have an immediate means of establishing multiple logins ( wifi and ipad flakiness...)
Global variables are session based, meaning that one user can't compare against the other user. That's why I suggested a table to record the login. The server setting for disconnecting idle users was my suggestion for dealing with users that leave their DB open overnight.
Someone could make a lot on a server plugin if they could mimic the action that (deniger) noted above of returning a list into a filemaker server script of anyone logged into the context of a specified file.
Since It exists in the Java console, I would figure that data's got to be able to be read out somehow.
Best we let Wolfgang explain further before delving into this more.
yes I know. Which was why I wondered if run with full access would make them (global var) persistant, just as setting global fields under full access makes global fields persistant.
using a script , set to run with full access privileges, to set a global field to the account name, allows the global values to persist across sessions, even when the script is executed by a data entry only account.
The same might be expected to happen for global variables; but it doesn't.
<<Global variables are session based>> true, but one might also say global fields are sesion based; but for fields it depends what whether a full access account or not is setting the value. Hence it was a consideration if the same behaviour appllied to $$var.
sorry, for beeing unclear with my question and now i know i have to be mor precise asking the forum. thank you for discussion.
i ment one user exclusiveley per session time. we have a server hosting 87 physical files. 40 of them are visible during login window.
there are mac, windows and ios client devices. users work on different devices.
we have 20 possible users with 4 different rights. 3 of the users have to report time und user critical data so we were thinking about helping these users with that kind of control.
for my opinion the best would be a server side control or a script like Get(AllActiveUsers).
as this is not available today we will discuss a solution storing active users in a table and checking the table in the morning. if there are users left und one of the 3 can not login, administrator has to act. for now i don't see a better solution.
Thank You All
There's nothing you can do in the FileMaker client to "police" people who log in multiple times from multiple workstations or devices. About the best you can do is set a short time for idle logout in the Server Admin Console:
If you set an appropriately short idle logout time (say, 1 - 2 hours), then users will be forced out on whatever devices they're not using at the time. It's a poor fix, but it's about the best I'm aware of at the time.
Edit: I should probably clarify what I mean by "police". There's nothing you can do from a client / FileMaker script to force another client to disconnect. You could, in theory, use a sessions table to record whether a user had previously logged in and deny access to the database if he hadn't logged out. However, there are some problems with this approach:
1) If a client is abnormally disconnected (network drop, power failure, etc.), then the session table won't get updated and the user will be forbidden from logging back in. Bad.
2) It's really annoying to the users even it if does work properly. Picture this scenario: User forgets to log out at the office. He goes home, attempts to log in from his home computer or iPad, gets denied permission. Do you really want to tell him he has to go back to the office and log out? Eep.
In theory, you could use a combination of a short idle time disconnect and a sessions table to ensure only one login at a time, but problem 1 still exists. You'd need to have an administrator to override the system in case of an accidental disconnect. Probably more trouble than it's worth.
just as setting global fields under full access makes global fields persistant
But that is incorrect. Global field values persist per session, as well. If you have a global field value at the start of the session, it is because the value either was set via startup script, or it had been set while the file was used single-user, before being hosted.
<<or it had been set while the file was used single-user, before being hosted.>>
<<just as setting global fields under full access makes global fields persistant>>
I am seeing those 2 line as much the same thing. I was thinking about setting global values that users will inherit but not recognising I was really thing about something like a file version global, that they can't change anyway.