6 Replies Latest reply on Apr 14, 2015 2:34 PM by twelvetens

    Webdirect Security



      This is a fairly general question regarding how secure one can 'lock down' access to a filemaker solution hosted via web direct. If I have a single file, which has been developed for an in-house team to access via FMP, and now we want to add the functionality to allow guest users (WITHOUT authenticating) to access a specific layout, and related table via web direct, in order to make applications for an event, to what lengths do I need to go in order to ensure that the web user cannot find their way to layouts, or more specifically to data that they shouldn't be allowed access to.


      My plan is this:


      1) Create a privilege set which only has access to the fields in the "web" table

      2) Also only allow the "web" privilege set to edit a single layout

      3) Remove all toolbars from the web direct layout with a script trigger on layout enter


      Anything else I should be doing?


      I'd really like to keep this all in a single file, if possible...

        • 1. Re: Webdirect Security
          Mike Duncan

          You might consider creating a second file that automatically logs in with the lower privilege user account you want to construct. That user account can match a user account in the main file, but without auto-login. Once they are in the new file, you can jump to your main file. Would that work?

          • 2. Re: Webdirect Security

            Set an "open script" (one that runs when the database opens) and use it to check the privilege set name - then disable toolbars / menubar and direct the user to the one layout. 

            I would also, as you say, create a new privilege set that only had WebDirect access and only to the bare minimum of fields & layouts you need. 

            • 3. Re: Webdirect Security

              Hi, forgive my ignorance, but what does this actually achieve? I'm not really understanding the benefits, and in any case, I'd rather keep everything in a single file, as it's a hosted solution, and I get charged for every file...

              • 4. Re: Webdirect Security

                Both good answers, but I guess I'm also interested in how secure the web direct environment is to nefarious activity, i.e how hard/easy/possible is it for someone to circumvent the measures I've outlined above?

                • 5. Re: Webdirect Security

                  Since all the views and data are processed server-side before being passed to the client, WebDirect is fairly secure against the most common website based attacks, such as bruteforce/DDoS and SQL injection, as long as you acknowledge that it's only as secure as you make your solution. Thorough testing should vette out any weaknesses in your solution so you can address it.


                  Mike Duncan's suggestion of using a second file is more secure for webdirect, as you can completely isolate it and shut it down without affecting your main solution should problems arise.


                  In general though, the server will only process instructions that you make available via webdirect. So if you disable the menus, make all navigation button based, secure your privilege sets for data, and isolate your webdirect layouts, then it would be very hard or impossible to circumvent your "bubble".

                  • 6. Re: Webdirect Security

                    Thanks All, great info.