Download Now!
Documentation

Contents
1. Quick Setup Instructions
2. Before You Begin
2.1. Important Questions
2.2. Requirements
3. Installation and Setup
   3.1. Quick Setup
   3.2. Download
   3.3. Uncompress the Archive
   3.4. Modify Perl Scripts
   3.5. Transfer files to the web server
   3.6. Modify File Permissions
   3.7. Run the Admin Application
4. Troubleshooting Installation
5. Getting Started
   5.1. Basic Concepts
   5.2. Calendar Display Basics
   5.3. Calendar Admin Basics
6. Administrative Application
   6.1. Login Screens
   6.2. Events
   6.3. User Admin
   6.4. Calendar Options
   6.5. Global Options
7. Customization
   7.1. Display Templates
     7.1.1. Template Introduction
     7.1.2. Template Procecssing Flow
     7.1.3. Template Example
     7.1.4. Tag Syntax
     7.1.5. Special Calendar Tags
     7.1.6. Defined Variables
     7.1.7. Include Files
     7.1.8. Retrieving Events
     7.1.9. Template Debugging
     7.1.10. Advanced Notes
   7.2. Template Reference
   7.3. Customizing Admin Templates
   7.4. Language Translation
8. Plugins
   8.1. Concept
   8.2. What Plugins Can Do
   8.3. The Basics
   8.4. Adding Permissions
   8.5. Adding Admin Menu Options
   8.6. Adding and Overriding Templates
   8.7. Adding Custom Functionality
9. Advanced Usage
   9.1. SSIs
   9.2. Command-line
10. Security Considerations
   10.1. Changing File Locations
   10.2. Encrypted Passwords
   10.3. File Locking

Printer-friendly Documentation

Security Considerations


Changing File Locations

By default, your 'calendarscript' directory will exist in the same place as the actual CGI perl script files, usually in the cgi-bin folder. There are two cases where this will not work well, however:
  1. If no files or directories under the cgi-bin directory can be set with CHMOD 777.
  2. If your web server is mis-configured, and a web browser can browse through the contents of the 'calendarscript' directory.
Most web servers will not allow people to browse the contents of anything under the cgi-bin directory. If a server is not configured properly, however, a user might be able to load the /cgi-bin/calendarscript/ directory in the browser and look at the contents. This would include the config files, events files, and schedules for all events. If you have calendars which are password-protected or events which are private, or if you are just security-conscious, this is not acceptable.

In these situations, it is recommended that you move the 'calendarscript' directory to another file location, preferrably outside of the document root of the web server.

Doing this will cause the script to longer be able to find the files anymore, however, so you must then go in and edit the $BASE_DIR line in the two Perl scripts to point to the new location of the files. For instructions on how to do this, see the Troubleshooting Installation section.

Encrypted passwords

Passwords for users are stored in the users.txt file, in encrypted form. This means that even if someone is able to view the file, they will still not be able to view the actual passwords.

Some systems, however, do not support Perl's crypt() command which encrypts the password. If this is the case, then the program will either fail or the passwords themselves will not be encrypted.

File locking

Since the calendar is a multi-user environment, meaning different people may be editing configuration entries or adding events the same time, file locking is required. This prevents two processes of the script from colliding with each other when reading/writing data to/from files at the same time.

Some systems, however, to not correctly implement Perl's flock() call to lock files. If this is the case, then the application will continue to function as normal, but files will not be locked and corruption of data is possible. For this reason, do not use operating systems such as Windows 95 to serve this program.
Home | Features | Demo | Pricing | Download | Documentation | Support
CalendarScript 3.21 ©Copyright 2003-2014