Security
Does DayBack respect FileMaker's Access Privileges?
Yes. But remember that some access rights may not be reflected in DayBack's interface. For example, if you have record level access privileges set so that a given privilege set can't see a record, then that record won't show up in DayBack. No problem.
But if FileMaker's record level access says that a given privilege set can only edit a record under certain circumstances, that record will appear editable to logged in users since DayBack can't evaluate the access rights until the user tries to edit it. So users will be able to, for example, drag an event to a new date: the drag just won't take and will be reverted after users see a dialog saying the action isn't permitted.
How Do I Secure DayBackForFileMaker ?
SeedCodeCalendar is distributed without any security in place; there are no accounts or passwords set up whatsoever. You’ll likely want to add some security to your copy as you deploy it. If you have an existing FileMaker solution to which you’re adding the calendar, you've likely already secured your events table: we have some notes about this when we talk about getting ready to integrate.
If you don’t have an existing security solution in place, you’ll want to set up at least some basic security for the calendar:
a) You’ll want to prevent you users from modifying the schema (field definitions, scripts, and layouts) of the calendar. Even if you allow schema modifications to the data tables like events, you’ll want to prevent such changes to the CalendarInterface and CalendarRows table where most of the interface work of the calendar takes place. You want users to be able to change the data here, but not the field definitions, scripts, and layouts.
b) Users should also be prevented from accidentially deleting or creating new records in the Calendar Interface. An easy way to accomplish this is to use Custom Menus to remap the New Record and Delete Record commands, pointing them to a simple script like this (delete record is an example)
If records are created or deleted accidentally closing and reopening the calendar will check to see if these interface records have been created or deleted and the calendar will automatically correct itself.
Can I Restrict Users to Only Seeing/Editing Their Own Events?
Definitely. More here: Only See My Events.
Hiding "Account Settings"
If you'd like to prevent some users from getting to the Account Settings window, you can edit the script "Load Calendar Settings - On Startup...". Find the comment "Show admin settings" and set the following variable to False for the privilege set you're interested in. So you might do something like:
After changing anything in this script, run the "Upon Opening" script to see your changes take effect.
Does running this in a webviewer make it any less secure?
The great thing about the way we are utilizing Javascript in the new calendar is that all of the files are downloaded from a FileMaker container field to the client machine when the file opens and are all run locally. So at no point does that code get read or written online. It is stored securely in a field where it cannot be executed and then transferred to a local folder (temp directory) where it cannot be accessed remotely.
So the short answer is that there are no additional security implications from our Javascript interface.
