Security Options

Use Cookies to Remember UserIDs

Set this option to "yes" if the calendar is to automatically populate the "username" field in the popup window with the last username entered. This will save end users about 4 seconds of typing time.

Use Cookies to Remember User Passwords

Set this option to "yes" if the calendar is to automatically populate the "password" field in the popup window with the last password entered. This will save end users about 4 seconds of typing time. This value is stored in a browser cookie, which should not last when the browser is closed. Enabling this option leaves open a potential security hole as user's passwords will be retrieveable if users do not close their browser window!

Show Fields to allow a user to edit an event

Selecting "yes" will display the appropriate buttons and fields to allow a user to add an event. If enabled, ALL users for the particular calendar can add an event.

To disable, select "no". Disabling this feature will allow only the "administrator" and "webmaster" (for this calendar) to add events.

In order for either the "webmaster" or "administrator" to be able to access the fields to add/edit/move/delete events, they MUST access the calendar through a special URL. The URL is the same as the usual URL, except the string "&ao=0" MUST be appended to it. DO NOT GIVE THAT URL TO YOUR USERS!

Examples:

If you have a calendar whose abbreviation is "demo1", you would provide the following link to your regular users:

• ASP: <A HREF="/scripts/calendar/calendar.asp?dept=demo1">


• Perl: <A HREF="/cgi-bin/calendar/calendar.pl?dept=demo1">


• PHP: <A HREF="/scripts/calendar/calendar.php?dept=demo1">

Your webmaster/administrators would thus need to access the calendar via the following URL in order to add, edit, move, or delete events:

• ASP: <A HREF="/scripts/calendar/calendar.asp?dept=demo1&ao=0">


• Perl: <A HREF="/cgi-bin/calendar/calendar.pl?dept=demo1&ao=0">


• PHP: <A HREF="/scripts/calendar/calendar.php?dept=demo1&ao=0">

Note that even if users know this "bypass" and call up the form with the input options, they still must provide a valid webmaster/administrator username and password to do actually make changes.

Allow Anonymous Postings

If enabled, a user can add events without supplying a username and password. However, an "anonymous" user can only move, edit, or delete events that have been entered by another anonymous user. That is, if an event has a username associated with it, then only that user, the calendar's "webmaster", or the "administrator" can move, edit, or delete the event.

Individual Calendar Users/Passwords

This is where the usernames::passwords are specified for each of your calendar users. Enter one username::password per line. Usernames and passwords MUST be separated by double colons "::".

Users have no ability to sign themselves up or automatically remove themselves from a calendar. Only "webmasters" and "administrators" have this ability.

Users have no ability to change their passwords. Only "webmasters" and "administrators" can change passwords to individual users.

Calendar User Permissions

Select the permissions users should have for this particular calendar. The "administrator" and "webmaster" can do anything to this calendar, and are not affected by these permission settings.

• Select "edit" if users should be able to edit events they originally added to this calendar. If this option is unchecked, a user cannot go back and edit one of their events.



• Select "move" if users should be able to move events (from one day to another) they originally added to this calendar. If this option is unchecked, a user cannot go back and move one of their events.



• Select "delete" if users should be able to delete events they originally added to this calendar. If this option is unchecked, a user cannot go back and delete one of their events.

The above permissions are specific to the calendar they are assigned to. For example, if there are two calendars "Number1" and "Number2", and "delete" is enabled for "Number1" but not for "Number2", then if a user chooses to delete an event from both "Number1" and "Number2", they will not be able to delete the event from "Number2"!

Allow users to enter HTML in the event "Description" field

Select "yes" if users should be able to enter HTML codes within the description field for their event. Otherwise, set to "no", and plain text only will be accepted.

A short message next to the "Description" field will be displayed informing the user whether plain text is expected, or if HTML can be entered. If enabled, a "preview" button will appear next to the description field allowing users to preview their posting.

If the Use PopUp option is disabled, then the preview link will NOT be available because it uses a popup window to display the preview.

HTML input is NOT allowed for any other input field.

Restrict Access to only the above Calendar Users

Set to "yes" if it is NOT ok for the general population to view this calendar. The only individuals which will be able to view this calendar are the users specified for this calendar, the webmaster, and the administrator (who can view any calendar).

When access is restricted, users will be prompted for a username and password before proceeding to the calendar. Anonymous users will NOT be allowed to access the calendar!

Netscape Users!: It is important to note that Netscape either has a "bug" or "security enhancement" with its implementation of javscript (depending on your point of view). If you enable this option and also the "use popup window", then you will potentially have to relogin everytime you add, edit, move, or delete an event from the calendar. This is because the javascript "reload()" function DOES NOT repost (resend) form data when instructing the browser to reload a page (despite the fact hitting the "reload" button does). This is NOT a bug in my program, and there are no secure work arounds that I know of. However, please send me an email if you know how to do it! :)