Jump to content

Granular Approach To Specific Script Access


GisMo

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

Recommended Posts

I'm trying to take a different approach to Roles and Script Access in a solution that a bit more flexible to change and create roles via the UI, not FMs native security. While "Hide Object When" is very useful, it's not always practical especially when there are multiple roles and it's not easily maintained across a system.

Conceptually what I'm thinking is:

  • Every button is attached to a script
    • the script attached to the button is used for navigation, to perform a task, or combination of both
    • these script are ONLY attached to a button and never called from within another script. They can simply be wrappers if needed
    • the current script being executed is known using get(ScriptName)
    • These button script names are human readable and prefixed with same identifier .e.g "Button."
  • In Every button script, we run another script which takes a parameter of the current script being executed.
    • This script will query/check if the current user and/or role has permission to run this script. 
    • Result: We return a friendly message box saying "no access to this feature" and HALT OR we continue and run the script 
  • Create the Role records 
    • Somehow we dynamically create a list of scripts with the "Button." prefix <- this this possible? A plugin even?
      • Can you dynamically query the scripts in a FM file?(this is a hard thing to google)
    • Add each script to the role via permission table. 

Functionality could be enhanced by using multiple prefixes for the scripts as groups, so you could add an entire group of scripts to a role based on the prefix...Lots of ideas based on this.

Has this been done before? Can we query a FM database for it's scripts without using database design report?

Edited by GisMo
Link to comment
Share on other sites

It's common practice for a script to branch based on a user's privileges. But those privileges should be defined in the FileMaker security settings.

Also you can't dynamically create scripts. Nor can you call a script by calculation. So I think this may be messy to implement (aside from not being good security practice).

Link to comment
Share on other sites

Short answers to some questions raised:

 

  1. You can generate a list of scripts in a file by any of several methods.
  2. The parameter method has been used before.  It's not particularly foolproof.
  3. You can run a script by any number of processes other than through the FileMaker Pro UI.
  4. The Permission Table may well be susceptible to tampering and manipulation.

If you choose to invent your own "security" system, you create vulnerabilities not already present in the file.  You must address these vulnerabilities. When you use the tools FIleMaker, Inc. gives you, you can close vulnerabilities present in your file.

My recommendation is to use the tools FIleMaker, Inc. gives you and not to try to invent your own tools.

 

Steven

 

 

Link to comment
Share on other sites

37 minutes ago, Fitch said:

It's common practice for a script to branch based on a user's privileges. But those privileges should be defined in the FileMaker security settings.

Also you can't dynamically create scripts. Nor can you call a script by calculation. So I think this may be messy to implement (aside from not being good security practice).

I'm not trying to call a script by text/string. Basically each button script will perfom a "has permission" script. Checking the Role/Privilege Against the Script Name. I want a simple UI and central location to edit the roles. I suppose I could implement this into a large script, but this lends itself to typos and errors.

34 minutes ago, Steven H. Blackwell said:

Short answers to some questions raised:

 

  1. You can generate a list of scripts in a file by any of several methods.
  2. The parameter method has been used before.  It's not particularly foolproof.
  3. You can run a script by any number of processes other than through the FileMaker Pro UI.
  4. The Permission Table may well be susceptible to tampering and manipulation.

If you choose to invent your own "security" system, you create vulnerabilities not already present in the file.  You must address these vulnerabilities. When you use the tools FIleMaker, Inc. gives you, you can close vulnerabilities present in your file.

My recommendation is to use the tools FIleMaker, Inc. gives you and not to try to invent your own tools.

 

Steven

 

 

Hey Steven,

Thanks for feedback. Can you go into detail on Generating the List Of Scripts?

 

 

Link to comment
Share on other sites

Let's go back to first principles here.

FileMaker allows on a script by script basis for each role (and thus for all Accounts associated with that role) the ability to determine whether the user can access and run the script.  So, rather than trying to reinvent something else, why aren't you using the FileMaker Pro process?

 

Steven

Link to comment
Share on other sites

I think the issue GisMo -- and others -- have with the native security setup is that only full access users can modify it. If the app offered admin groups (something like FileMaker Server does), that might be the solution. Maybe someone should post this to https://community.filemaker.com/community/discussions/product-ideas/

Link to comment
Share on other sites

Completely agree with Wim.  There is no protection either for data, for structure, or for developer intellectual property by giving any category of users access to the security settings.  And it is the way it is now by purpose and design.

 

Steven

Link to comment
Share on other sites

Wim and Steven, I respect your expertise in this area. However, I do think there are scenarios where the FileMaker security settings don't provide exactly what people want. It comes up in online discussions fairly regularly.

  • Like 1
Link to comment
Share on other sites

Tom:

 

That's not really relevant.  It's not a case of whether the security settings provide what someone wants or not.

 

It's a case of whether if a developer chooses to implement something of his or her own creation, that the developer understands what vulnerabilities that introduces into the file that aren't there already, and whether the developer is willing to live with that risk for himself/herself and for the client involved.

My experience and observation over the past 15 plus years is that most developers do not recognize the vulnerabilities introduced by ersatz processes.

I am trying to prevent some major incidents occurring--that is otherwise likely avoidable--that damages the reputation of the Platform and the reputation of the developer community, and that results in the FileMaker Platform's getting shown the door loudly and dramatically.

 

Steven

Link to comment
Share on other sites

21 hours ago, Fitch said:

 don't provide exactly what people want. It comes up in online discussions fairly regularly.

And where it comes I very often challenge that exact premise.  Sometimes it is a "hammer and the nail" situation where the developer is more comfortable rolling their own than using the native controls.  (Granted: the Security area of a FM solution can use a serious overhaul to make it more intuitive).

Or lack of experience / eduction.  The fact for instance that EA can be used with local accounts and groups is almost universally overlooked.  Same with the importance of file access protection.

Link to comment
Share on other sites

Don't get me wrong, I agree with your points -- see my original response to the OP. I'm basically just saying what Wim says above: there's room for improvement in the security settings -- in the UI if nothing else -- that would help users achieve their goals and not feel like a workaround would be a better choice.

Link to comment
Share on other sites

26 minutes ago, BruceR said:

Further, I think that Steven still has not at all addressed my original point: 

Within an entirely LAN environment, what is the actual threat level?

I'm not sure I understand, Bruce.  Where were you in this conversation prior?  Am I missing a link to another conversation where you mentioned your 'original point'?  I would be interested in reading it!

Link to comment
Share on other sites

Bruce:

 

Did not see a question from you.  Within a LAN, there are any number of Threat Agents that could be at work:

  • Disgruntled employees
  • Supply chain actors (see, for example, Sony)
  • Outsiders who RAT a workstation on the LAN
  • Idle Curiosity players
  • Service personnel with access to the physical premises
  • Cyber-criminals using social engineering

 

Steven

Link to comment
Share on other sites

I asked my original question in another thread, your first as you promoted this new topic. I think the question of degree of exposure, and perception of degree of exposure, is valid and worth discussing. 

You ask why people ignore your advice or find it not applicable or incomprehensible. Like the security measures you claim are important, maybe the human model needs description and discussion.

Link to comment
Share on other sites

6 hours ago, Wim Decorte said:

And where it comes I very often challenge that exact premise.  Sometimes it is a "hammer and the nail" situation where the developer is more comfortable rolling their own than using the native controls.  (Granted: the Security area of a FM solution can use a serious overhaul to make it more intuitive).

 

The one area where I think the FileMaker security model could be improved in by implementing an inheritance model. Often times I want one Role to have access to "A", a second Role to have access to "A" + "B", and a third Role to have access to "A" + "C". If defining "A" is complex, doing it three times introduces the possibility of error between the three implementations. Furthermore, if I add new functionality that users with access to "A" should have access to, I need to add that access to three places instead of one. Otherwise I agree, most people who "role their own" don't need to.

Quote

Or lack of experience / eduction.  The fact for instance that EA can be used with local accounts and groups is almost universally overlooked.  Same with the importance of file access protection.

One thing I would add to this is the use of Extended Privileges which both can allow you to define security in a less granular way and the management of which can be delegated to trusted users. This might be useful to GisMo as a way of "rolling your own" but doing so within the FMP security model.

  • Like 1
Link to comment
Share on other sites

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