Web DevelopmentWeb Development esembrat3 Wed, 01/21/2015 - 09:43
This section contains content system agnostic web design and development documentation and knowledge.
Web Development Sub-Topics
Appearances and ThemesAppearances and Themes esembrat3 Wed, 01/21/2015 - 09:45
This section contains generic appearance and theme-related resources for web development on campus.
Please be sure to also see the Georgia Tech Web Branding Rules for Georgia Tech's specific website standards and requirements.
Appearance and Theme Sub-Topics
CSS Preprocessing (Sass)CSS Preprocessing (Sass) esembrat3 Wed, 01/21/2015 - 09:54
CSS preprocessing allows you to write shortcode, functions, variables, and other time-saving methods for building up your website CSS.
The preferred tool on campus for CSS preprocessing is Sass.
Sass is an extension of the CSS framework that is already in wide usage across the web. However, Sass provides scripting capabilities to make writing CSS easier. Sass compiles Sass commands, variables, and references into cut-and-dry CSS that can be interpreted by websites.
Sass-written CSS looks very similar to the CSS you already know, with a few new features.
Getting Started with SassGetting Started with Sass esembrat3 Fri, 02/03/2017 - 11:26
Getting started using the Sass preprocessor is easy, provided you have experience with command-line interface tools.
The recommended setup for writing Sass on campus is:
The Ruby Sass release and Compass.app have been deprecated or phased out.
To get started, unpackage the Github package gt_sass_template into your theme's directory.
- All files in your /css/ folder will be overwritten when compiled. So, if you want to save your custom CSS so far, convert your CSS into Sass.
Once you have the package into your theme directory, run node-sass by:
- Open Terminal.
- Navigate to the folder to which gt_sass_template was installed to.
./startupto run the node-sass compiler and watch status.
Now, any changes you make to a Sass file will be compiled into CSS.
HTML/CSS Templates for Creating Georgia Tech WebsitesHTML/CSS Templates for Creating Georgia Tech Websites
You can find a repo of a static HTML/CSS template for creating a Georgia Tech website available on the Georgia Tech Github page.
To access the template, please see:
You must have an active Georgia Tech account in order to view this repository.
The markup and styling associated with this repository is ported from the Georgia Tech Drupal theme. This template serves as a starter-kit to help one follow Georgaia Tech Website Brand Requirements when building a static Georgia Tech website or website in a content-management system other than Drupal.
SecuritySecurity ma195 Tue, 02/03/2015 - 12:12
This section has security related resources including authorization and authentication techniques, data encryption techniques, and security best practices.
Central Authentication Service (CAS)Central Authentication Service (CAS) kp37 Tue, 03/21/2017 - 18:09
What is Central Authentication Service (CAS)?
From Wikipedia (Central Authentication Service):
The Central Authentication Service (CAS) is a single sign-on protocol for the web. Its purpose is to permit a user to access multiple applications while providing their credentials (such as userid and password) only once. It also allows web applications to authenticate users without gaining access to a user's security credentials, such as a password. The name CAS also refers to a software package that implements this protocol.
Georgia Tech implements the CAS service to allow campus members to easily log into campus websites using their GT Account Username and associated password. However, for a website to utilize CAS, it must be set up correctly, which usually means adding a module, plugin, or library, and configuring it to work with Georgia Tech's CAS servers.
- Setting up CAS for Drupal 7 - Georgia Tech Drupal Article
- Setting up CAS for Drupal 8 - Coming Soon
- Setting up CAS for WordPress - Coming Soon
- Setting up CAS for a stand-alone PHP application
- Setting up CAS for a static website on OIT Web Hosting - OIT FAQ Article
CAS and Stand-Alone PHP ApplicationsCAS and Stand-Alone PHP Applications kp37 Tue, 03/21/2017 - 18:27
The most common approach for adding Central Authentication Service (CAS) support to a custom stand-alone PHP application is through the phpCAS Library. As of mid 2017, the most recent version was phpCAS 1.3.5. Note: If you are using an earlier version you should upgrade as soon as possible to obtain the latest security patches.
The basic approach to using the library is to unpack it into a subdirectory of your application, require the library's main file, then add the appropriate calls to it before you application does anything that requires the user's identity to be known. It is preferable to store the user's identity in a session cookie for later accesses, so that you are not authenticating the user against the CAS server on every single page access.
Note: You would not utilize phpCAS in this manner if you are wanting to add CAS authentication to most content management systems (CMSs), such as Drupal or WordPress. Instead, you should look for a CAS module or plugin for your particular CMS, and use it. These modules and plugins are designed to integrate CAS into the CMS's user management system to give you proper security and a good end user experience. Not every CMS will have a CAS module, but most of the popular CMS's will. If you can't find a CAS module for the CMS you are using, you could look at it's module/plugin API and see if you can write your own module or plugin to integrate phpCAS, but this requires a fairly advanced knowledge of PHP programming, the CMS in question, and the CAS protocol.
SSL EncryptionSSL Encryption ma195 Tue, 02/03/2015 - 12:12
SSL encryption (technically Transport Layer Security, but still commonly referenced as SSL, the acronym for its now deprecated predecessor) is a protocol for encrypting communications between a web browser and a web server. Encrypted connections (denoted by a web URL starting with 'https://') are not easily monitored by third parties unlike unencrypted connections (denoted by a web URL starting with 'http://'), where all content can be easily viewed by anyone with access to some part of the connection path. SSL works through a system of public-key cryptography, and is intended to not only keep communications private, but to also help ensure that you are actually communicating with the right server and not a hacker's rogue server that is merely impersonating a legitimate server.
By default, SSL is provided and available on OIT Webhosting, and can be enabled other types of on-campus web hosting where you or your information technology support staff have low-level management access to the web server.
In order to enable SSL encryption for a website, you need to have an SSL certificate that securely identifies that your server is the genuine server for your website's domain name. There are many possibilities for obtaining an SSL certificate – too many to list here.
Presently, Georgia Tech is a member of InCommon, a collective of universities which have pooled resources. This means campus units can get SSL certificates for free. Usually one person in a department, college and/or school has the ability to request and issue certificates. Ask your information technology support staff for assistance if you need a certificate for a web site.
InCommon Certificate Caveats
- Georgia Tech's InCommon account can only [documentation needed] issue certificates for sub domains of Georgia Tech (addresses that end in .gatech.edu). If you need a certificate for a non-Georgia Tech domain, you will most likely have to obtain a certificate through an outside service, which will most likely require a yearly fee. Check with your information technology support staff for more information.
- If your site is on OIT Web Hosting, you may not need a certificate, as web hosting has a 'wildcard' / multi-site certificate that covers a lot of common Georgia Tech sub domains, and they are often willing to add additional Georgia Tech sub domains if you ask. Please see the OIT FAQ Article on SSL Certificates and Web Hosting for more information.
Other Types of SSL Certificates
Before InCommon, there were several options for SSL certificates. You may stumble across them:
- Paid SSL certificates - Issued by GoDaddy, Thawte, Comodo and others.
- Self signed certificates - Generated and signed on the server that hosts them. These are fine for development, but should never be used in production, as users will get a certificate error message in their browser when accessing a site with a self-signed certificate.
- Georgia Tech Signed certificates - For many years, Georgia Tech had its own root certificate. It's no longer used, but may still be on systems. If you find this, you should remove it, as the root certificate has expired, as have any certificates signed by that root certificate.
Implementing SSL Encryption
Security Best PracticesSecurity Best Practices kp37 Fri, 03/10/2017 - 12:41
Patch, Patch, Patch
The most important security practice for web application software is to keep up with your software patches. The more commonly used the application, the greater a chance that someone out there is looking for insecure installations to hack.
Systems like Drupal and WordPress are so popular that you need to be prepared to deploy security patches for them just as soon as they come out. If your hosting server is running Installatron, you can configure it to automatically install many of these updates. If you don't have Installatron, you can still configure WordPress to automatically install new updates on its own. Drupal, unfortunately, requires manual intervention if you don't have an outside tool like Installatron, but modules can usually be updated from within the application. Drupal core updates have to be installed from the command line or from a web hosting file manager control panel.
Non-security patches can be important, too, but should be tested more thoroughly before deployment since they could break things. (Security patches could break things, too, but sometimes it may be better to break a small feature of your site temporarily than to leave it susceptible to a known vulnerability.)
Lock Down Site Access
Securing the back doors to your site is pointless if you leave the front door wide open. Make sure you have configured your web application properly so that only the proper authorized people can access it.
- Consider user roles carefully and don't give out more access privileges than are necessary.
- Audit user access lists and remove users who no longer need access (employees who no longer work for your unit, students who have graduated, anyone who has moved to a different role that doesn't need to use the application.)
- Besides auditing access lists within web applications, also audit the access lists for their server hosting accounts as well. Make sure that the people with access to administer those accounts still have reason to be doing so. Take old developers off of these accounts if they aren't actively working for you, even if you think you'll bring them back in later, and remove anyone who has left Georgia Tech, as they could potentially still be able to get to your hosting account even after many of their standard IT privileges have expired.
- If you implement a configuration where anyone with a GT Account can log into your application, be very careful about what you make available to these 'regular' users. Keep in mind that when you include all GT Accounts, you include all guest users, outside vendors and developers who are doing work for Georgia Tech units, retirees, alumni, etc. That's a pretty big pool of people. If you really don't need to include all of those people, look into options for validating that someone logging in is a current faculty/staff member or student.
- If you add custom security modules to content systems like Drupal and WordPress, don't just assume they work as you have configured them: open a different browser and test to make sure a non-logged in user really can't get to the content you are trying to protect. A security configuration that doesn't actually work is worthless.
Run a Tight Ship
Module and plugin based applications like Drupal and WordPress have one distinct downside: not all modules and plugins are created equal, and poorly written and managed ones can put your application at risk.
Before installing a module or plugin, review it carefully. Avoid ones that do not have active support, ones that haven't been updated in several years, and ones that have never left alpha/beta status. It's usually better to tell a stakeholder that there's nothing available to provide a certain functionality than to offer up a module or plugin that isn't stable and risks introducing security holes. It's also far better to say no up front than to try something that stakeholders get used to, only to later discover a serious uncorrectable problem that necessitates removing the plugin/module.
What's a Frankensite? It's a module/plugin based web application where so many extra components have been added to it that it's impossible to properly audit the functionality of the site. Upgrading these sites can either become impossible, or strokes of pure luck if a major update doesn't break several things at once.
When any kind of complex functionality is required, look at abstracting that functionality out to a separate application that can run in parallel with the main application. For example, if you are running a Drupal site and your stakeholders want a nice photo album, don't load up the Drupal site with the half-dozen extra modules needed to make a barely functional internal photo album system. Instead, set up a copy of ZenPhoto, which is designed from the ground up to handle photo albums. Or, suggest the usage of an online system like Flickr or PhotoBucket. Any of these options will keep your main website application from turning into an unmanageable Frankensite.
(Setting up multiple applications may seem like more work at first glance, but it's far less work in the long run, as you'll be able to streamline the installation of updates, not to mention that you can update the secondary applications one at a time without having to bring down any others or the main application/site.)
Enable and Monitor Security Logs
Many applications and all hosting account systems will log different kinds of activity related to your web application. While a lot of these logs may seem unreadable to the untrained person, they could still be invaluable should a problem arise - especially a security incident. It's a good idea to keep these logs around for at least six months, and even longer if your application handles any sensitive data. Check the Georgia Tech data security policy to find institute requirements and recommendations for log retention.
When possible, sending logs to a remote server is a really good idea, as that prevents those remote copies from being modified by a hacker who gets too far into your web server.
Make Regular Site Backups
Nothing is worse than having a site crash without a recent backup available. Whether the crash was due to a patch gone bad or a hacker getting into the site, being able to restore the site to a previously known good state is critical. Here are some recommended guidelines for handling backups:
- For all sites, run a full backup once a week, and for important sites, also run an incremental backup daily.
- Store backups in a safe location, ideally on a remote server. If possible, configure your infrastructure so that the web server can't modify a backup once it's been written to the remote server, so that a hacker who breaks into the web server can't delete your backups.
- TEST your backups! Far too many a systems administrator has been bitten hard by backup files that were corrupted, missing important components, or even just plain missing because the backup process didn't write out the files as expected. After running your first backup, download the files and try to recreate the website in a test environment to make sure you have a complete backup of the site. And, don't forget to check the backup archives periodically to make sure they're still functioning as you expect.
- Be sure to cycle out old backup files periodically, so that your backup system doesn't run out of disk space. This is yet another way to discover that you have no recent backups when you need them the most.
Install and Utilize Security Tools
Some applications may have third-party tools to help you monitor for security problems. A good, reliable security tool can block many types of known attacks, stop brute-force login attempts, log more details about accesses to the site, and/or point out configuration settings that you ought to change to make the site more secure.
Since every application is unique, you'll have to research the available security tools that work with a specific applications. Be sure to look at how well respected the tool is within the user community, as that will give you an idea of how safe and reliable it will be.
There are also server level security tools that you can utilize, such as Web Application Firewalls (WAFs). These have to be installed by a server administrator, but can add an extra layer of protection beyond the tools available for the specific application(s) you are running. The OIT Web Hosting servers all run a WAF that protects their hosting accounts by filtering any requests coming from off-campus.
Write Safe Code
If you are coding applications for the web or even just coding modules / plugins / themes for existing applications, take the time to write safe code:
- Sanitize any user input that you utilize to deter hackers from running malicious commands by submitting carefully crafted values into a form field.
- Use proper security wrapping methods to make sure that authorization is being checked properly before the execution of any higher level command.
- Avoid putting in a backdoor "just for testing", as it can be all too easy to forget to remove it later. If you must use one, document it boldly and clearly so that it's easy to detect when you review the code later.
- Do carefully review your code before putting it into production, and even better, have someone else review it as well, since they might catch bugs that aren't obvious to you.
- Always keep a copy of your code on a separate server, so that if your development or production servers get hacked, you can run a code comparison to your protected code to see if anything was changed by the hackers.
Clean Up After Yourself
Leaving junk behind in your public web hosting account directories can cause multiple problems, so keep your public directories clean:
- When installing code updates, keep the installers out of your public directories, or at least move them out once you are finished with the update. If your hosting account doesn't already have a private directory, create one and use it for installers, backups, etc.
- If you edit live code, don't leave any backup copies in the live directories. If you need to make a backup of a file before editing it, put the copy in a private directory. There are many ways in which an improperly named backup file could accidentally expose the program code to a hacker, and depending on the file, this could expose internal user account credentials, shared secrets, or internal server names, all of which could be quite valuable to a hacker.
- If you run a major update and want to move your current installation to a different folder, once again move it somewhere inside a private (non-public) directory, especially if there is no need to be able to access the old installation over the web. If you do need to leave the old installation up temporarily, plan a date at which it will be shut down, and if at all possible, firewall that directory for the interim to just on-campus IP addresses (or if possible, just IP addresses for your local unit). Old installations usually never get patched, and thus can become huge forgotten security holes if left publicly accessible over the web.
- Security precautions aside, keeping your public web directories neatly cleaned up will help you in many other ways, including making it easier to debug problems and in some cases even speeding up application performance.
Suppliers and ContractsSuppliers and Contracts esembrat3 Wed, 01/14/2015 - 10:27
This section covers all aspects of having websites created or managed by someone outside of your Georgia Tech unit, such as hiring a consultant from another part of campus, or using an outside web development company.
Suppliers and Contracts Sub-Topics
Georgia Tech Web Design ContractGeorgia Tech Web Design Contract esembrat3 Tue, 01/27/2015 - 09:54
This page details the Georgia Tech Web Design Contract active as of January 2015.
What is the Georgia Tech Web Design Contract?
The Georgia Tech Web Design Contract allows units on campus to request and receive web design and development work through pre-approved suppliers without having to go through the usual RFP process for selecting and working with a supplier. This allows for campus web projects to be initiated faster and to work with suppliers that understand Georgia Tech's web infrastructure, platforms, and restrictions.
Georgia Tech Web Design Documents & Updates
The Georgia Tech Campus Web Suppliers website houses documentation, updates, and details for both on-campus units and off-campus pre-approved web suppliers.
Web Design Contract Sub-Topics
Starting the Web Design ProcessStarting the Web Design Process esembrat3 Wed, 01/14/2015 - 10:28
In January 2015, Georgia Tech finalized the Small Web Project Specification and Large Web Project Specification. This change drastically simplifies and accelerates the process for evaluating and selecting suppliers for web development work.
Please note that you must complete the BuzzMart training before you can view, evaluate, and select a supplier in BuzzMart. The training takes approximately 1 hour to complete for Shopper access. See details at Procurement's website.
For questions about completing the training, contact Procurement & Business Services.
Selecting a Supplier
To view suppliers for a small or large web project, follow the directions below:
- Log in to TechWorks.
- From the TechWorks homepage, select the 'Access Buzzmart' icon from the middle column.
- From the left black bar, select the shopping cart icon ('Shop') and select 'Browse By -> Contracts'.
- On the Search for Contract page, type 'web' for Contact Keyword and click Search.
- On the results page, all suppliers with contracts of "Web Design Project - Small/Large Job" are Georgia Tech contracted suppliers.
- Click the contract number to view the Contract Summary.
- Each contract contains a SUPPLIER GENERAL INFORMATION WORKSHEET. Supplier information (email, phone) will be available for you to contact the supplier and initiate a job. You may contact the Contract Owner (Teresa Holcomb) to discuss how to select between suppliers.
- It is recommended for any job greater than $10,000 you request a quote from multiple suppliers.
- Services of $5,000 or greater require an approved CTR.
For any questions about this process, contact Purchasing at Procurement & Business Services @ email@example.com.
Starting the Project
Once the supplier has been selected, initiating the project is just a few steps:
- First, ensure that the estimate you received from the supplier matches the pricing matrix for the supplier listed on BuzzMart. This is required for initiating the project and will be denied if the pricing does not match.
- The Business Partner/Contact for your unit must create a Requisition Request in BuzzMart.
- Once the Requisition Request has been approved, a Purchase Order will be assigned to the project, and work can begin with the supplier.
- Institute Communications recommends that any large web design project first meet with them to discuss any resources for branding, theming, and additional assets. Contact your Client Manager to begin this process.
- Scope changes, additional work over the estimation process will require the re-submission of documents (CTR, Requisition Request) to match the updated costs.
Large Project SuppliersLarge Project Suppliers esembrat3 Wed, 01/14/2015 - 10:27
A large RFP project is defined as a project requiring multiple areas of feedback and deliverables, large development, and long-scoped projects. These projects usually cost more than $25,000.
An example of this project is:
Complete redesign of an existing site using Drupal 7
Large Project Suppliers
- Enablus LLC
- Mediacurrent Interactive Solutions
- Simply Web Inc
- TBS Communications Inc (dba)
- Whats Up Interactive LLC
Small Project SuppliersSmall Project Suppliers esembrat3 Fri, 01/30/2015 - 14:51
A small RFP project is defined as a project requiring a simple web-related task to be completed. These projects usually cost less than $25,000.
An example of this project is:
Migration of an existing site to Drupal 7
Small Project Suppliers
- Not yet available.
Supplier Scores & PricesSupplier Scores & Prices esembrat3 Thu, 02/12/2015 - 11:30
In order to assist web projects in determining the RFP scores (technical prowess and expertise) and pricing matrix (pricing scales), an extra document has been added to each supplier contract on BuzzMart.
Each supplier contract on Techworks has a document titled [SUPPLIER NAME] Pricing Matrix & RFP Scores. This document contains (in order):
- A pricing matrix provided by the supplier listing suggested pricing for example projects.
- A scoring matrix of the supplier compared to all similar suppliers on the project list.
Please note that a high cost score on the scoring matrix translates to a lower cost supplier.
On-Campus Contract WorkOn-Campus Contract Work esembrat3 Tue, 01/27/2015 - 11:39
On-campus web developers can, in some cases, serve as contractors for on-campus web work.
- Please note that is strongly advised that you receive direct agreement from your supervisor and the hiring unit's leadership before beginning work.
- To simplify the process, the best practice is to complete this work outside of the employee's regular working hours.
5.3.2 Extra Compensation:
Extra compensation may be paid to employees for tasks performed after normal business hours for duties not included in the employee’s normal job responsibilities, provided the following three criteria are met:
The tasks must be outside of the employee’s regular department.
The Departmental Agreement Form, must be completed and signed by the appropriate department heads. Departmental Agreement Form
The employee must meet at least one of the criteria listed below (Criteria from the Official Code of Georgia Annotated Section 45-10-25):
- Certified Oral or Manual Interpreter for Deaf Persons
- Registered Nurse
- Licensed Practical Nurse
- Teacher or Instructor of an evening or night course or program
- Professional holding a doctoral or masters degree from an accredited college or university
- Part-time employee
Also, an employee meeting all three criteria listed above may be paid extra compensation for a task for another department during normal job hours if the task is not part of the employee’s normal job responsibilities, and the employee takes annual leave for the portion of time that is being used for the task receiving extra compensation.
Employees that have been determined by the institution to be non-exempt, as defined by the Fair Labor Standards Act (FLSA), and are performing extra duties could qualify for overtime pay. Non-exempt employees should be paid at least the overtime rate or more.
Examples of situations justifying the payment of extra compensation are:
An employee teaching a continuing education course after hours or while taking annual leave, when teaching the course is not part of the employee’s normal job responsibilities.
Note: This is allowable under the Official Code of Georgia Annotated Section 45-10-25, No. 15.
A part-time public safety officer working extra hours to referee a ball game.
Note: Georgia Code 45-10-25 does not apply to part time employees.
A staff member with a masters degree doing web design for another department.
Note: This is allowable if the required Departmental Agreement Form is completed and signed by the appropriate department heads.