use the Relogin script step at the beginning of the script.
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...
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.
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.
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.
I believe Soliant did a demo for that.
Quick and dirty.
agnes b. riley
filemaker and web development
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
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!
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.
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.
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.
...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.
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!
I've yet to move this partik'lar client to FMP13...