Jump to content

account password


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

Recommended Posts

Hello all!

I've been trying to implement a limit on how a user can access my solution but I believe I can't figure out on my own how to avoid somebody to override the password as it is been happening in my experience.

When you open a file that contains accounts, a dialog box usually prompts you to enter account information. If you open the file with a correct account name and password, the privilege set assigned to that account determines what you can do in that file. Entering invalid credentials will result in the error, "The account and password you entered cannot be used to access this file. Please Try again".

Now this is my dilemma:
When the file is set to open, it prompts the user to input the valid credentials and if not, the login window will advice to re enter as you know, showing the following options:
A: cancel
B: ok
If you hit " cancel", then it will prompt to:
Cancel or continue.
If cancel, it will cancel, if continue it will ....continue with the  "admin" password or any other previous user password to perform the script which is a violation of the idea.
Why is it that the filemaker allows that to happen?
Did any one experienced this behaviour ?
I hoped I explained this well!
Thanks in advance




Link to comment
Share on other sites

In my experience, there should be no Script at this stage.

They either have the correct credentials or they don't - and then a script may or may not run...

See the attached - User: Admin pwd: filemaker gives you full access, User: test  pwd: test gives you data entry. No other combination should allow you in...


Link to comment
Share on other sites

From your description I would guess that the file is already set to open using the account crudentials entered in the file options dialog.  A script is then running which asks for a re-login. If the re-login fails filemaker is simply asking if the script should continue which it will do with the previously established credentials. This is simply a case of filemaker doing as it is told by who ever wrote the script. This pretty much illustrates the dangers of using a scripted login process. The strength of the security becomes dependant on the skill of the developer who wrote the script. And even still, once the file is accessed using the credentials in File Options, even if that is a limited account ( which it should be instead of an admin account ) there are then ways that a savy hacker can use to interrupt the scripted process and gain access.

Link to comment
Share on other sites

Thank you webco. Could not open your link. I m still 11.

And Ron, thank you too for your response.

The thing, my friends is that  a script is necessary ( at least I see it that way) in order to re-login into the solution.

I'm just stuck under those parameters. The whole solution works really well, but I want users to be responsible for the inputs.The only way I see it working is creating accounts to id the users while creating records and can't understand why is there such a simple way for filemaker to allow a previous credential to take over when the one intended to use the right password fails to do so.

I may try (again) to lure the the system to change the user to a guest account with "read only" so that  password is the last entered and becomes the previous user. I tried this before but my mind was tired and did not get the desired resultl

If anyone has a better idea in order to help me, i will really appreciate it,  otherwise I'll ask webco to guide me into the best infested shark Australian beach and throw me self into it!

All the best to y'all!


Link to comment
Share on other sites

29 minutes ago, nad1 said:

a script is necessary ( at least I see it that way) in order to re-login into the solution.

A script is necessary to re-login - i.e. in a situation where User A is already logged in, and now you want them to log out and have User B log in instead*. The question then becomes what exactly does your script do - because by default, if the Re-Login[] script step fails, then no re-login has occurred and User A remains logged in as before. If you don't want this behavior, you must explicitly specify another.

(*) Although technically, you could demand that User A logs out completely and User B logs in from scratch.

Edited by comment
Link to comment
Share on other sites

I have tried everything that I know. I have closed the file and that is the only way that the "continue" part will not work, but the whole idea about passwords being entered at re-login is that you would have not to close the file so that user B can get in with credentials and do entries under a B  account.

Can't really understand it. It may be an issue of being a single user license?.... i guess that could be it and why allow the other passwords then to exist in the first place?

I can't figure it out.


Link to comment
Share on other sites

It has been explained.

The re-login script will attempt to login with the new users password - if that fails, and they press Cancel, then the login will still remain as the first users....

This is expected behaviour.

- Have the users close the database when changing from one user to another. This means that there will be no one logged in when the login attempt is made, and if they fail, it will not let them in at all
- Make the script trap for an incorrect login, and be performed again until they get the login right

Link to comment
Share on other sites

Thank you guys!.

Through your responses and comments I concluded that I had to create another database, that contained a very simple task: to make all others be logged off. The same database would re-open the main file with a guest password and once there, everyone needs to make a fresh re-log-in. Once all the the steps required to entered data into the main file, a script will make sure all related files are closed for the next user ensuring that is them not others that are in.

I finally understood how it works.

Webko: pretty much  you suggested it in your last post that I just read. Thanks a lot!. I came to the above conclusion before reading your post but you are right on!

My previous assumption was that the re-log function made all the steps in order to make sure whomever was logged to be off. That was the ignorance on my part and opening up this discussion made the whole problem go away.

All related files need to be closed before any other user attempts to enter with his/her credentials. This way ensures that the "continue" button will not be used at all (that is why I couldn't understand the logic behind its purpose) and logging off completely will make sure that the system will not be entered with data with the previous user credentials if that is the way it happens to be while in use by the incorrect user.

Well, thanks again. I am still learning and certainly this dialogue served as a catharsis process to my ignorance by opening the road with much clearer signs. I am really grateful to y'all!




Link to comment
Share on other sites

This concept is fraught with fragility.  If the scripts are interrupted, or if the "Guest" log-on can be manipulated, people will be into the files in a state you perhaps you did not anticipate.

Use the tools FileMaker gives you for security.  They are good tools.  Do not try to invent your own tools; they likely will introduce vulnerabilities to your system not otherwise present as the people in the 2FA thread discovered. 




Link to comment
Share on other sites

20 hours ago, nad1 said:

Through your responses and comments I concluded that I had to create another database

I don't see anything in the "responses and comments" given here that would warrant such conclusion.


Edited by comment
Link to comment
Share on other sites

This topic is 1879 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.