13 Replies Latest reply on Sep 25, 2014 12:04 PM by johnbuckingham

    Ask user for their password


      I've been asked by the Financial Director of one of my clients to write him a report. But the content of the report is one that he would prefer not to have available for any staff to see.


      I've added a button to his (and only his) startup menu to run the report. But he asks if it is possible that the scripting behind the button requests he enter his password before proceeding so that a visitor to his office can't gain unauthorised access to the report in his absence.


      I can't think of an obvious way to script this. Especially as he prefers I test his 'real' password rather than comparison to a string in the script.


      Its probably real simple, and I can't see it: So any suggestion as to how this may be achievable in FileMaker 12 will be gratefully received...

        • 1. Re: Ask user for their password

          use the Relogin script step at the beginning of the script.



          • 2. Re: Ask user for their password

            Hi Malcoml


            Thanks for your suggestion. I had thought of that but my reason for rejecting it was that, if the intruder is an authorised user, they could then enter their own Username and Password and thus gain access. Then quit FileMaker...


            However, I could do that and test the Extended Privileges of the then current user.


            Thank you for making me think more clearly...

            • 3. Re: Ask user for their password

              You could have the script relog him in and then verify that his account is

              in a  specific privilege set.


              If the login fails have it close the file.


              I just did something similar that only let's specific staff run reports.






              Sent from my mobile device... Please excuse typos.

              • 4. Re: Ask user for their password
                Stephen Huston

                Because you cannot assign extended permissions to individual accounts, only to permissiong groups:

                If this user doesn't have his own permission group in that file, maybe it's worth duplicating the permission group he now uses, setting the script accessibility slightly differently so only that "group" can see/execute the reporting script in question, and then reassign him to that new permission.


                You could still require that he relogin just to verify it's not someone else at his computer while he's at lunch, but you need to do some error trapping to be sure the relogin process isn't just cancelled by the user.

                • 5. Re: Ask user for their password

                  The simplest would be a re-login script step with a check. If the re-login is successful (no error) and the current account name is the Finance Director's continue, otherwise exit.


                  No need to mess with privilege sets or extended privileges.


                  I wouldn't close the file, what if the director mistypes his info, that's annoying.

                  • 6. Re: Ask user for their password

                    Throw him to a layout where you ask his password with a web viewer/javascript solution. Store his password in a script and run that upon entering the password and match against entered data.


                    I believe Soliant did a demo for that.


                    Quick and dirty.




                    Best regards,


                    agnes b. riley

                    filemaker and web development


                    download vCard


                    TWO-TIME MAD DOG AWARD WINNER

                    FileMaker Certified in 10 and 11 • Member, FileMaker Business Alliance

                    T: 877 917-9079 . C: 917-660-7221

                    Store | Blog | Facebook | Twitter | LinkedIn

                    • 7. Re: Ask user for their password

                      Thanks, everyone. Its great to know there are people who are willing to help when you hit 'the wall'...


                      I did use a relogin - thanks Malcolm, Bruce and David. But I also invoked an Extended Privilege (I know where you're coming from, Stephen - but if the MD clicks the button on the FD's screen, I reckoned it would be best if he could also see it!). I have been in discussion with the client recently and we've agreed that each member of staff has their own set of startup menus and will soon have their own set of Extended Privileges - so everyone there (13 souls fttb, more soon) will be in a group of one.


                      David; I see what you mean but that seemed to me to require embedded logic, whereas the Extended Privileges seemed to allow a more generic approach. Maybe I misunderstood...


                      agnes; I love quick and dirty, but I'm not quite sure I follow that one yet; I'll delve into Soliant's site and track down the demo - it sounds interesting!


                      Again; thanks to you all for taking the time...


                      And if you're in Leavenworth, WA, over Christmas, let me know so we can maybe get together and chew some FileMaker fat!

                      • 8. Re: Ask user for their password

                        Using Extended Privileges is certainly more robust. It does bring some more overhead.


                        Are you confident you've got a firm grasp on the three elements of security privileges though? There's Accounts, Privilege Sets, and Extended Privileges. I'm asking because not clear if everyone needs their own extended privileges though with "...have their own set of Extended Privileges - so everyone there (13 souls fttb, more soon) will be in a group of one" and that doesn't make much sense in this context.


                        If you do go with Extended Privileges, I recommend a simple custom function to help manage those:

                        has.Privilege ( name )  =

                        not isEmpty ( FilterValues ( Get ( AccountExtendedPrivileges ) ; name ) )


                        If you're truly worried about other staff coming in and attempting to run the report, you probably don't want to use the Re-login[] script step raw. Use a custom dialog to capture the password and then pass it to a "No dialog" Re-login[]. That way someone can't even try to login as someone else.

                        • 9. Re: Ask user for their password

                          Thanks, David


                          I think I do have a reasonable grasp of the Extended Privileges in the context of security privileges in general, but its always good to recap...


                          What I was trying to say in respect of the way I have decided to work, and I can see that I may have used a confusing grammatical construction, is that each user will have their own name as their Group (i.e. each user will be '...in a group of one') as well as their User Name. This will allow a very granular control over what actions individuals can perform. For instance, if 'PatternCount ( Get ( AccountExtendedPrivileges) ; "canDuplicateSalesRecords" ) = 1' then the [Duplicate this Sales record] button/script will work for them. I had to do it this way because, for this client, there seems not to be an obvious hierarchical basis to who can (or can't) perform some functions. So I was spending a lot of time trying to allow/disallow various actions and Extended Privileges seems, in such a small user base, to be much the easiest way.


                          Wouldn't it be great if we could assign Extended Privileges to Users as well as to Groups?


                          And huge thanks to Draconventions '2empowerFM' which allows me to find scripts that reference my exisiting 'UserLevel' globals and thus to replace them with an Extended Privileges test instead.

                          • 10. Re: Ask user for their password
                            Stephen Huston

                            Another thought: if you are going to create a bunch of buttons on menus. You can use the Hide When to make a button disappear if the user name or permission group isn't the one intended to use it.


                            This wouldn't replace the relogin check, but it would limit the risk of others trying to use a button to run that script.

                            • 11. Re: Ask user for their password

                              ...so that a visitor to his office can't gain unauthorised access to the report in his absence.

                              I'm generally hesitant to do a "one off" password verifications, especially with this kind of consideration in mind. If other users shouldn't be able to run this report, chances are there are other things a random user shouldn't be allowed to do, either.


                              We generally include a "log out" feature, which is a bit different from just relogin. With relogin, if you fail, you're back to whatever user logged out. With "log out", we log the user into a user account and priv set both called "logout", with very limited access (no viewing data, etc., just access to the log out function), and then do a relogin. What this means is, when the user is leaving their computer, they log out, and someone who wants to use their computer needs to log in with their own credentials, so that they're operating under their own privileges, and we're accurately tracking who did what.


                              Just my two cents.


                              Chris Cain

                              Extensitech, LLC

                              • 12. Re: Ask user for their password



                                Thank you for that; it's a very good idea. I had noticed that the relogin allowed a cancel option and wasn't sure how to get round it. Obviously, David has found a way to prevent it with the 'No dialog' relogin method, but this appeals to me as another way of dressing the same beast: I shall implement that immediately!


                                Thank you!

                                • 13. Re: Ask user for their password

                                  Hi Stephen


                                  I've yet to move this partik'lar client to FMP13...