8 Replies Latest reply on Apr 8, 2012 11:20 AM by karendweaver

    Security - Logging in


      Hey all,

      How do you deal with keeping a database secure while working with user's preferences of keeping their password in their mac keychain?


      At my school, all the teachers use filemaker for daily student-information. I gave them a separate file that opens the actual hosted/remote file while on campus. Most teachers have set their username and password to be in their keychain so that it opens quicker. But to me that's not secure.

      What should I do with that? As I deploy this out to three schools, I have to tighten up on security and am not sure how to keep people from storing their passwords in this database housing confidential student information.




        • 1. Re: Security - Logging in

          Hi Jeremy


          I think the most common solution is to have a relogin script on startup.  In other words, the database automatically opens for EVERYONE with a guest account or some other account with very limited access - possibly even a session record or a screen with no table data.  Then the opening script runs a relogin that requires the user to enter their user name and password to continue. 


          If you go this route - I would reset all the passwords so that if someone was able to view the previously saved password in the keychain tool, they still wouldn't be able to use it for the database. 


          Hope that helps.



          • 2. Re: Security - Logging in

            People probably won't like that, but I think its necessary. Anyone could get into our student's information if they logged in using the computer of a teacher.


            I'll set the main file to do a relogin script.




            • 3. Re: Security - Logging in



              See this post by Kevin Frank. It talks about the keychain in Macs and may have some relevant info for your situation.






              Doug de Stwolinska

              • 4. Re: Security - Logging in

                I read that post and really like it. Thanks Doug, for the tip. I will read all filemakerhacks posts. 


                A question: one of the issues we have at our school is that on the laptops of teachers, when they close the laptop and then open it up again, filemaker says that the communication has been interrupted and filemaker the file will close.

                Some teachers hike all over the campus in a day and are frustrated that they have to restart the database. They use the keychain access to get in faster. I fear the teachers and the administration will not be happy about having to log in every time they shut their laptop.


                I still want them to log in everytime, but they're not going to be happy about having to redo it everytime.  I may have to teach them that they should leave their cover open as long as possible.

                • 5. Re: Security - Logging in

                  Hi Jeremy,


                  It looks like you've got a good handle on how to handle security and are wrestling instead with the balance between the need for security and the human desire for convenience.


                  At the end of the day, these two things are to some degree necessarily at odds with each other.


                  Until the computer itself can recognize if the correct person is using it, some level of inconvenience is unavoidable.


                  Note that confirming the user of the computer might bypass this inconvenience...but it would take place outside of Filemaker (biometrics for example) and be based on who is touching the computer in the first place.


                  People don't like to believe that THEIR laptop would ever be misplaced or lost...but that doesn't ake the liklihood any less...or the possibility any less real.  "Such a thing would never happen to ME! "


                  Please take this post simply as kudos for wrestilng with the need to secure sensitive data...and best wishes in your endeavor.

                  • 6. Re: Security - Logging in

                    Jeremy, it isnt just closing their computer that will disconnect them - this will also happen if the computer goes to "sleep" or if they are walking around somewhere where there isn't a good wireless connection.  And it is a bad idea to close the computer while the database is open - what if there was a script running?


                    Definitely, you need to train them.  Start with a required training that covers these issues before they are allowed to get a user name and password to the database in the first place.  That will help with new teachers, at least.


                    It is inconvenient, but you are right, this is sensitive data, and teachers should care that it is protected.  If they don't, I suspect there is a training gap at your school..  ;-)  Most teachers I work with are extra vigilant about these things.


                    At the same time - there are some things you can do to help make things less painful for them.  ( a trade off - lose some convenience but gain some )


                    First - give them a "close & save" button or script that they can access from everywhere that saves the users current status in the database.  This can be done several ways  - you want to save the current layout, save the current found set, the current record, end any running scripts, and quit FileMaker or close the database.  Maybe they can send themselves a snapshot link that restores the status (although I find those are kind of kludgy, especially if there are a lot of them - I prefer a script - then you can also restore their window settings.).  Also with a script to close - you don't have to worry about interrupted scripts.  This does require a "users" table where you can save these settings (DON'T save the passwords, of course, but it is okay to save the login name.)


                    Put a shortcut to the database on their desktop - they still have to log in, but they don't have to open FileMaker, navigate to the host or favorites, click on the database, etc.  Just click on the shortcut to launch FM and take them to the automatic login screen, then immediately to where they were when they left.


                    It IS a pain to get in and out of a database all day long.  It IS a pain to have to reconnect to the server when you get kicked out (especially if it hasn't been long enough and the server thinks your are still connected so you get the dreaded License Key conflict message.  ugh. )  SO let them know you feel the pain and you are trying to help, while still requiring that sensitive data is protected.  win. win.


                    some people will complain no matter what, but most will be so thrilled with the easier connections, they will compromise on the passwords... 



                    • 7. Re: Security - Logging in


                      Arg. I had no idea one could set up a system to do that - to save the current layout/record etc that a user is on. I'm going to explore that.


                      You're right: we have a big training gap in technology in our school. Most users have little to no idea what they can do on their own, which is another question I have.... 


                      Our school hasn't placed a huge emphasis on professional development in technology thus far. I've developed this system (I am a decently competent developer) and people use it. But i've had little opportunity to train people. Moving into a half-time teaching, half-time database developer/technology coordinator, I will insist that something more happen.


                      How do you create that save button?

                      Create a users table, as you suggested. In that, record the account name, the current layout, the current record??  I'll have to search that out. I suppose there are Get functions that will record that for me.


                      Thanks for the feedback about how i can develop better, and for the information about this particular issue. I have so much to ask about how to be a 'real' developer. I've learned on my own over the past three years reading books, asking lots of questions, and trying something. 


                      I'll let you know how it goes.

                      • 8. Re: Security - Logging in

                        Hi Jeremy


                        You are exactly right - save the info in a users table.  I am attaching a very simple file with a user table and startup and close script, that saves the last layout and then returns to it.  This will auto open with the user name Admin, full access, no password - but turn on the script debugger and data viewer before launching so you can watch what it does in the open and close scripts.  Play with creating different users, etc.   Note - there is no error trapping in this sample file.  What will happen if the last layout the user was on is renamed or deleted??   Experiment with this and watch the errors so you can determine what to do.


                        Basically, I use a "session" table that is created on login and deleted on logout to keep track of things the user may be doing during the session that don't need to be saved on logout.  Then on logout, the close file CAN save anything that I want to save.  You could ALWAYS save when the user closes the program, then you don't need a button, but I would have them choose - they don't always need to save where they were, and it is good to get them purposely closing the program to save - if they close the lid on the laptop - no save..


                        You can start with the file attachment if you like and then experiment with different techniques for saving user settings.  And yes, the Get functions can return much of what you want.  Saving the found set is a little more complicated - and there are many ways to do it.  I am attaching a link to ONE possible way demonstrated on Matt Petrowsky's FileMaker Magazine website, but do some searching - I am sure you will find more.  This one may or may not be the right one for you.


                        I  highly recommend Matt's website for lots and lots of techniques, videos, and demo files.  It is subscription based, but the subscription is only $25 per quarter and he regularly posts new technique files with video explanations.  You can download the technique files and take them apart, watch the videos for a detailed explanation, AND with a subscription you can search his entire archive - EVERY article ever posted -  for what you need.  In addition, he regularly posts "free" articles - no subscription required, so you can watch some of those and get the flavor of what he has. 


                        For example, here is a link to one of his articles about saving user found sets that is relevant to what you want to do:




                        Hope that helps!!  Happy FileMaking!  ;-)