Purpose

This document is intended for third party or outside developers who are developing Drupal sites in whole or part which will be housed on the SAS Computing central Drupal server (Virgo). Due to the shared nature of the server environment and the commitment of SAS Computing to the highest level of support and uptime it is necessary to impose certain restrictions on all sites (and code) that will be deployed on Virgo.

Environment

Developers may choose one of two methods for which to develop new Drupal sites. Each method requires different considerations:

Non-Penn Hosted Dev Environment

If a developer so chooses he/she/they may host their own development environment. SAS Computing can provide documentation as to the current version of the software stack supporting Drupal (including MySQL, Apache, PHP, Drupal, modules, etc.). Development environments should be made to match these specifications as closely as possible to avoid deployment problems.

If developers choose to maintain their own dev environments then no access to Penn systems will be required. Once the project is complete, the developer can deliver the MySQL database and the required templates, themes, and module code to Penn staff for deployment.

Penn Hosted Dev Environment

SAS Computing maintains a development server that mimics our live server in almost every way. Drupal code is synchronized to this development environment directly from the live server. This development environment is a multi-site Drupal installation so it closely replicates the live server.

In order for an outside developer to get shell access to the development server they will be required to get a PennKey. Only PennKey holders will be given accounts to the development environment. Without first obtaining a PennKey, development on our testing server is impossible. Please initiate a PennKey request as soon as possible if you intend to utilize the Penn hosted development environment.

Access to the Penn development environment is granted via SSH (which supports SFTP). Developers will be given access to their home directory and the 'sites' directory for the site they are developing. Shell access will allow developers to interact with MySQL using the account assigned to the Drupal site. No additional ports or software will be opened or installed on the testing environment for database access (no PHPMyAdmin or remote port 3306 access). It is possible to tunnel connections over SSH so a remote developer could access the MySQL database using GUI tools from their local environment by tunneling the connection.

Note

During development and for the purposes of testing, new Drupal sites will be installed on a development environment that mimics the production environment. All changes and updates to code, as well as development, should be finalized on the testing environment. Once code is deemed stable it will be ported to Virgo by SAS Computing staff only after a thorough security audit. In order to speed this transition, as well as to insure the safety and security of all sites on the testing environment it is important to adhere to all security guidelines at every stage of development.

Modules

Each module installed on the Drupal development server must undergo a thorough security audit before being deployed. Many modules have already been approved through this process. Please reviews this list, carefully select the additional modules you wish to employ, and request security reviews as early as possible. Security reviews insure that modules deployed on our production environment are stable and free of security problems. This protects your site as well as other Drupal sites.

On average it takes about 4 hours to review each 1000 lines of code in a Drupal module. The ISUS staff have 8 hours a week to review modules, so two small modules can be reviewed in a week. Be sure to plan for this time delay when requesting new reviews of modules. Please be aware that this time estimate is very rough and some modules may take more or less time to review depending on their functionality and complexity.

Modules that are marked as unstable, buggy, or not fit for production environments in their own documentation will not be installed on the production environment in order to protect not only your own, but others' Drupal sites.

It is a good idea to check the outstanding issues with a module you're requesting. If there are lots of active bugs reported, especially if many of them are critical, this may be a sign that the module isn't stable.

Modules that are designated 'alpha', 'beta', or other pre-release, by the developer typically indicate that the code is either incomplete, buggy, or otherwise unfit for prime time. We are hesitant to approve these modules because they are inherently subject to change (as they move to beta) and for the reasons stated above.

Modules that are labeled as 'dev' are unsuitable for production environment as they are specifically designated for testing and debugging. In order to provide the highest level of integrity for all centrally hosted Drupal sites we will not install any 'dev' modules.

Be sure to select only modules that have versions for the currently installed version of Drupal. Also be sure to note any prerequisites or supporting modules that must be installed in order to install the module you are requesting. Some modules require several dependencies and these may inflate your audit request significantly.

Custom PHP

All PHP code should be restricted to modules. Templates should be utilized for display purposes only. Every effort should be taken to minimize the use of PHP code in the templates. PHP should never appear in CSS or directly within node content.

It is important that developers follow the Drupal secure coding guidelines posted by the Drupal security team. Following these guidelines will insure that code avoid common security pitfalls.

The PHP input type has been removed from the production environment (Virgo). No site or module should require the utilization of PHP code through the Drupal web interface. All PHP code should be produced by developers and packaged in appropriate module or template containers.

File Uploads

File uploads are restricted to images and office documents. If other file types are needed (such as video or executables) for site completion, please inform SAS Computing staff at the earliest possible opportunity.

Comment Settings

Anonymous, unapproved comments with full HTML should not be allowed. This presents a link spam opportunity for attackers and opens the door to inclusion of malicious JavaScript and cross site scripting vulnerabilities in comments.

Node Creation

Only authorized users should be able to create nodes. Content creation should be limited to authenticated parties that have been vetted by Penn staff.