Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 6935 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

Hi bmohnsen,

You haven't provided much here, ie, like your login process/script but you can use globals quite effectively in this instance; whether in a Preferences (or User table) with one record or not. Startup script should then contain:

Set Field [ Preferences::gUser ; Get(AccountName) ]

... where gUser is the global. Since it is global, that value can be accessed (or SET) from anywhere in your solution (even if unrelated). It will not persist (remain after shutdown) in multi-user but that's fine. Because you will set it yourself.

A terminate/re-login BUTTON script (to allow Users to change systems) or simply exit might look like this:

Show Custom Dialog [ " SESSION TERMINATION ". Buttons will be: "Terminate" ; "Re-Login" ; "Cancel")

If [ Get ( LastMessageChoice ) = 3 ]

Halt Script

Else

If [ Get(LastMessageChoice) = 2 ]

Re-Login ... uncheck Perform without dialog

Set Field [ Preferences::gUser ; Get(AccountName) ]

Halt Script

End If

End If

Perform Script [ your Shutdown script here. ]

I hesitate showing this script here because startup/shutdown and User-tracking is an individual call (kinda like fingerprints) so each solution should be evaluated independently. But this will give you the idea, I think. :wink2:

UPDATE: Do NOT store passwords anywhere in your solution. Let FM handle them for you through proper login routines.

LaRetta

Posted

Thanks for the info - I guess I don't know enough to explain myself.

I have a file with three tables - one table is for login--one record with three global fields. In a second table is the name and password. When the user types in their name and password in the log in layout - the name and password is compared to the name and password in the other table - if there is a match then the user gets to enter and go to their individual record.

My question is - what will happen will two people on two different computrs try to log in at the same time - if the file is on a server?

Posted

I guess I wasn't explaining myself very clearly either ...

WHY are you, not only storing passwords in fields, but storing them TWICE (one in each table)? Why bother to have passwords at all? I assume you have nothing in these tables which needs to be protected; either from your employees, or a thief which steals your hardware, or even potentially online intrusions. I hope you realize that anyone in your company, even someone not computer-wise, would be able to get into either of those files in two minutes flat REGARDLESS of how you attempt to restrict them to certain layouts because those passwords are EXPOSED.

"what will happen will two people on two different computrs try to log in at the same time "

I don't know your process (and scripts). You still haven't given me enough to tell you whether your process will work and I refuse to guess on something this critical. But if you use a script to set data in a global based upon a specifc User, that data will be independent for each User - that's one of the great qualities about globals. That won't be a problem for you. Which is good. Because you will have other problems to deal with.

I understand wanting to store the AccountName but NOT passwords ...

FileMaker's own password protections are better than what only a few Developers are capable of replicating. The script I provided takes the best of both worlds ... gives you AccountName so you can track User movement, data-change etc, but lets FM handle the password aspect. I again suggest you drop the passwords from your tables. But using the globals for storing AccountName will work great. :wink2:

LaRetta

This topic is 6935 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.