8 Replies Latest reply on Aug 23, 2012 5:53 AM by philmodjunk

    Restricted Found Set

    JimMac

      Title

      Restricted Found Set

      Post

      I want to restrict access to a Contacts table to AgentID's created records only and the managing Broker.  Agents should not have access to other Agent's contacts. The Contact table is password protected for each Agent.

      now i have this...

      AgentsID ----------<Contact::AgentID --------<Notes::AgentID and ContacID[unique and seq]

      BrokerID -----------<Contact::BrokerID

      Each agent must "copy" [actually just a non modidfiable field in each contact] each Contact to Broker with Timestamp of the copy to prove when the contact was made and alert the Broker.

      I need to prevent AgentID =4 from seeing AgentID =9 contacts.

      any thoughts?

      Jim...

        • 1. Re: Restricted Found Set
          philmodjunk

          First you need a table of agents with the AgentID field in it the field that then generates the ID value used in these relationships. I imagine you have that part already. In that same table, add a field for their current account name.

          Use File Options to set up an OnFirstWindowOpen triggered script with this code:

          Go to Layout [Agents]
          Enter Find Mode []
          Set Field [Agents::AccountName ; get ( AccountName ) ]
          Perform Find[]
          Set Variable [$$AgentID ; value: Agents::AgentID ]

          Then you can set up a "lock expression" in Manage | Security like this:

          $$AgentID = Contact::AgentID

          Note that if a user or a script performs a find on the Contact table, all access denied records are automatically excluded from the found set. The only way they can add such records to their found set is with Show All Records or Show Omitted Only and then they are covered with a grey screen and the words "access denied".

          You can use custom menus if you have advanced, to modify the show all and show omitted menu options so that even they do not add them to the found set.

          See "Editing record access privileges" in FileMaker Help and check out this particular sub section: "Entering a formula for limiting access on a record-by-record basis" for a detailed description of how to set this up.

          • 2. Re: Restricted Found Set
            JimMac

            Your assumptions are correct and I am FMP adv.  I know which AgentID is trying to access Contact Table, and their privilage set [Data Enty Only].  I think you are pointing me to create a NEW privialge set which resticts "limited" record access based on $$AgentID=Contact::AgentID and then Custom menu that Privilage set to eliminate Show All Records and Show Ommitted Only.

            If so Then...

            Is there any other "hacker" type way to display other AgentsID contacts?

            I had considerted a Contact portal but inconvient to add Notes and other Actions.

            Then wondered about a self relastionship or other easier method.

            Thanks

            Jim...

            • 3. Re: Restricted Found Set
              philmodjunk

              What I'm suggesting is pretty much the most secure method for controlling data access short of physically encrypting the data. As long as the "hacker" can't get physical access to the file (say through remote desktop access), it's pretty hard to get around.

              You do not have to use a custom menu as Show All Records and Show OMitted does not permit uses to actually view the data in these records. Modifying the menu is strictly a way to make things more user friendly by making sure they can't get a grey screen with Access denied on it.

              I did not describe removing these options. I described replacing their standard actions with perform script actions that perform scripts designed to "show all" or "show omitted', but that still omit the records for which they do not have access.

              There are a number of other methods, but they really put the responsibility on you not to accidentally open up a loophole that lets them in do to some design omission on your part. I recommend using manage | Security to control access and using interface design to "soften the harsh edges" that can be encountered when access privileges bar access to the data.

              • 4. Re: Restricted Found Set
                JimMac

                I will use GTRR based on AgentsID ---<Contact::AgentID [related records only] which an Agent should seldom see the [Resticed access screen]

                And...

                Do a New Privilage set restricting as you suggested, with the user friendly Show All Records... et al.

                And a Broker Privilage Set that allows total contact table review.

                Thanks for helping as always and in a clear and simplest way.Smile

                Jim...

                PS: I did know of this option but was worried about "loopholes"Undecided

                • 5. Re: Restricted Found Set
                  philmodjunk

                  Please note this less well known tidbit:

                  Enter Find Mode []
                  Set field [YourTable::fieldneveremptySuchasAPrimaryKey ; "*" ]
                  Set Error Capture [on]
                  Perform Find []

                  If you perform this script with a full access privilege set, it finds all records like you would expect, but if this script is performed while one of your agent level users has it open, it only finds those records the agent is permitted to access. All the access denied records are automatically omitted from the found set.

                  • 6. Re: Restricted Found Set
                    JimMac

                    Very nice tip.  What is special about your tip is...

                    Proof of FMP well done Security base programing....!!!!!!!!!!!!

                    In their master Application "loop",  the first thing they Check is Security, then proceed to next stepsCool.

                    Which is an important point in doing a new database.... Start with your intended SECURITY.

                    Phil, that caused a brain storm to stop "hackers" in my case [a simple cross check]

                    Example Logic...

                    Keep track of AgentID record count, by SetVariable[$$RecCount ; Get( FoundCount )]

                    Increment/Decrement $$RecCount based on my new New/Delete Record script.

                    Set a few Script Triggers to verify that $$RecCount = Get ( FoundCount )

                    wah lahhh....

                    Hacker trap!

                    Plus we never want to actually delete a Contact, but simply "hide" in or make them inactive. So I was headed that direction anyway.

                    Jim...

                    • 7. Re: Restricted Found Set
                      JimMac

                      Phil, after working through other problems I finally arrived at testing the Contact's file in a Muiti-User HOST [not server] security problems we discussed here.

                      In your....

                      Go to Layout [Agents]
                      Enter Find Mode []
                      Set Field [Agents::AccountName ; get ( AccountName ) ]
                      Perform Find[]
                      Set Variable [$$AgentID ; value: Agents::AgentID ]

                      Then you can set up a "lock expression" in Manage | Security like this:

                      $$AgentID = Contact::AgentID

                      the security is on the Contact file.  Here $$AgentID is on the Agents file.

                      FMP suggests what you said but shouldn't is be defined a gAgentID or $$AgentID in the Contact file, where the restricted set is defined?

                      If yes...

                      How do I assure that a second user doesn't change the globals.?

                      Jim...

                      • 8. Re: Restricted Found Set
                        philmodjunk

                        You have the right idea. You'll need to pass that information on to the other file in one way or another. Using a global field--an external file reference can make the same field accessible in both files, is one option, using perform Script to perform a script in the second file while passing the data to it as a script parameter is another.