Why not create real accounts for the web users, either inside FMP or in an LDAP, AD or OD.
that's not so easy.
The password field is made whtite text on white background, set to a very little size.
I have crated a scripttrigger on the password field.
Every keystroke modifies a visible field: Left ( "********************" ; Length ( AA basis::G login password ) ) & "|"
Only problem is it is showing both fields.
But is works.
There must be a better solution.
1 of 1 people found this helpful
The problem wimpog with using a global variable (or really any variable outside of a script) to store a password is that someone with low level access can ( if the user leaves open the file or machine ) open the data viewer and input the $$password into the Watch tab and see the value being stored. For security reasons...you will need to address that.
You can also use a webviewer, set the <input type="password"> and enter the value that way ( not tested in quite some time...but I have done it before ).
You can secure the script so that people can't access/debug it.
I believe, this is needed to prevent shoulder surfing, so why would anyone launch Data Viewer, when typing his/her password?
Your webviewer approach most likely uses the data url method, which isn't supported in all browsers, in particular in some IEs.
True...prevents shoulder surfing.
But if someone leaves their machine unsecured with the file open...you can open the dataviewer and access the Watch tab, regardless of the privilege set. And regardless of the privilege set, you can input any variable and it will return the value. Major security issue.
I've used the data URL in every major brower version...I haven't seen it not work. I've seen some odd behavior, but that was caused more by my own mal-formed html. lol
Well, you can clear the variable, right after the Enter key is pressed/password validated. In this case, the user has to type the password in, not press the Enter key, and leave his/her computer.
Data URLs work in all browsers, but they have some limitations. FTS briefly mentions them, you can find more details on the Web.
hehe...painfully aware of the limitations. But that kinda makes it fun. It forced me to learn html better so I can do some fun things with it.
This one, however, does work nicely. And doesn't require me, the developer, to remember to clear the variable. You could also use a local Variable instead of a global, then FM clears it when the script is over.
We don't manage the current AD (different department/ politics), though a separate AD could work it would probably take a long time to implement.
We will maintain control of account creation though, for security reasons though we can't create the passwords. I'm hoping to create temp passwords and script a first time login script to force them to change their password.
So going back to Vaughn's question. Can you just use FileMaker's user accounts/security? Rolling your own security model is inherently troublesome in FM, if you don't have a firm grasp on all the nuances. And still tough for even the most seasoned developer.
Not saying it's impossible, but more details on the exact requirements of the audit process would make it easier to narrow down a plausible solution.
Access to the FM Server is secured to onsite and allowed IP addresses off-site (this is few, and as far as I know only given to current employees who work from home, not external entities). This should minimize the number of FM Advanced users. Though I do understand the risk.
People can't access the data viewer from a web environment can they? It may be that we only allow app access for a small specific access privilage.
Is it possible to serve the HTML from within FM and have a form POST that way?
The SQL DBs are managed by a different department and the moment we do that there are cost issues and such. I did ask is we could host our own MySQL DB on the FM Server for user security, though haven't heard back yet.
If FM inc. are reading this, we want more control over passwords if FM 12 ever gets released. At least I would like it...
I can and intend to use their accounts, but I require a way to enforce the password creation. It must contain special characters, numbers, upper and lowercase letters. I have only seen a method to enforce password length in the FM security, am I missing something?
I'm investigating AD for managing all the accounts. Talking about running a separate service from the FM server solely to manage our FM accounts. Thanks for putting me onto this. I will respond when I've had a better look at. Thank you Vaughan and Joshua.