DayBackOnline

Security

DayBackOnline.Security History

Hide minor edits - Show changes to markup

July 02, 2015, at 08:13 PM by 142.4.217.188 -
Added lines 14-17:

Can I have some users with read-only access to the calendar?

Yes. More here: read only.

July 01, 2015, at 03:31 PM by 142.4.217.187 -
Added lines 1-4:

Does DayBack store my FileMaker account name or password?

No. This information only resides in the PHPrelay file you place on your FileMaker Server. It is not used in any DayBack database, cookie, or server.

Changed lines 7-8 from:

Yes.

to:

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 as 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.

Changed lines 17-27 from:

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 might do something like:

If ( Get ( AccountPrivilegeSetName ) = "[Full Access]" ; True ; False )

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.

to:

Only admins can see Account Settings. If you're of of the administrators for a DayBack group you can decide which group members have Admin access.

Does running this in WebDirect make it any less secure?

No. =)

July 01, 2015, at 03:24 PM by 142.4.217.188 -
Changed lines 1-19 from:

How Do I Secure DayBackOnline ?

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 [ Get ( LayoutTableName ) = "CalendarInterface" ]
Beep Show Custom Dialog [ Title: "Delete Record: Error"; Message: "You can't delete records this way: you're attempting to delete an interface record: click on an appointment directly to delete it.";
Buttons: “OK” ]
Else
Set Error Capture [ On ]
Delete Record/Request
End If

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.

to:

Does DayBackOnline respect FileMaker Access Privileges ?

Yes.

Added lines 32-37:

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.

Changed line 27 from:

If you'd like to prevent some users from getting to the Account Settings window, you can edit the script "Webviewer Settings". Find the comment "Show admin settings" and set the following variable to False for the privilege set you're interested in. So might do something like:

to:

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 might do something like:

Changed lines 29-31 from:
If ( Get ( AccountPrivilegeSetName ) = "[Full Access]" ; True ; False )
to:
If ( Get ( AccountPrivilegeSetName ) = "[Full Access]" ; True ; False )

After changing anything in this script, run the "Upon Opening" script to see your changes take effect.

Added lines 24-29:

Hiding "Account Settings"

If you'd like to prevent some users from getting to the Account Settings window, you can edit the script "Webviewer Settings". Find the comment "Show admin settings" and set the following variable to False for the privilege set you're interested in. So might do something like:

If ( Get ( AccountPrivilegeSetName ) = "[Full Access]" ; True ; False )
Changed lines 7-9 from:

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)

to:

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)

Changed line 11 from:
If [ Left ( Get ( LayoutTableName ) ; 8 ) = "Calendar" ]
to:
If [ Get ( LayoutTableName ) = "CalendarInterface" ]
Added lines 20-23:

Can I Restrict Users to Only Seeing/Editing Their Own Events?

Definitely. More here: Only See My Events.

February 03, 2010, at 10:50 PM by 76.22.123.157 -
Added lines 1-19:

How Do I Secure DayBackOnline ?

DayBackOnline 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 [ Left ( Get ( LayoutTableName ) ; 8 ) = "Calendar" ]
Beep Show Custom Dialog [ Title: "Delete Record: Error"; Message: "You can't delete records this way: you're attempting to delete an interface record: click on an appointment directly to delete it.";
Buttons: “OK” ]
Else
Set Error Capture [ On ]
Delete Record/Request
End If

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.

(855) SEEDCODE
[email protected]
Follow us: