New userpages sites are no longer being created. if you are creating a website for a class or instructional purposes, please use the Student Web Environment for Courses (swe.umbc.edu).
Transitioning from the Old Userpages Server (September 2017)
Changes to Locations of Available Interpreters
For web content that uses CGI, the path of the interpreter you selected may no longer exist. Please see this page's section on "Available Scripting Languages" to find out what the interpreter should be updated to.
Changes to Versions of Software
Our new userpages environment has more modern versions of all software. This may mean that older code/configurations which were written for an earlier interpreter/apache version may require updates.
Changes to the Way AFS Permissions Are Used.
Our old userpages system made a distinction between dynamic and static content. All dynamic content was accessed using the www.usercgi user while static content was accessed using the www.userpages user. For the new version of userpages www.userpages is used to serve all content. For the majority of our users, this change won't be noticed, but if you made extensive use of AFS permissions on your site, especially when it comes to dynamic content that writes to your webspace, your AFS permissions may need to be adjusted. You'll want to ensure that www.userpages has all of the privileges that www.usercgi has. Please refer to the openAFS documentation or submit a support ticket for more information on updating your AFS permissions.
Changes to .html File Interpreter
Our old userpages system interpreted .html files using a php interpreter. This meant that you were able to use PHP inside of your HTML files. The new userpages system will not interpret PHP that is inside of .html files. If you have PHP inside of files that have a .html extension you will need to change the extension on those files to .php.
Changes regarding SSL
Our old userpages would happily serve content from "http://" and "https://" addresses. The new userpages will redirect all "http://" traffic to its "https://" equivalent. This could have implications if you are submitting data via a form. If your form's action uses the "http://" address the webserver will perform a redirect and drop all of your form data. Changing your form's action to use "https://" should avoid that redirect and preserve your form data.
By granting the www.userpages AFS user read or write access to files you control you are exposing these files to:
- In the case of read access, be read by others who may execute CGIs on our userpages system. Any private information stored in those files could be disclosed.
- In the case of write access, be written to by others who may execute CGIs on our userpages system. Files may be modified or destroyed. New files may also be created which could cause your user volume to fill up.
Neither UMBC nor DoIT will take responsibility for the security or integrity of files stored in areas where the www.userpages AFS user has read or write access. We also ask that any user asking for "input" on web forms that store data in those areas make it clear that any information entered on such forms is stored using an insecure method.
Available Scripting Languages
|Language||File Extension||How To Use|
|PHP 5.4||.php||Any content in a file ending in .php will be interpreted by PHP|
|Perl 5.16||.cgi||Begin the file with "#!/usr/bin/perl". All content below that line will be interpreted by Perl|
|Python 2.7.5||.cgi||Begin the file with "#!/usr/bin/python". All content below that line will be interpreted by Python|
|Ruby 2.0||.cgi||Begin the file with "#!/usr/bin/ruby". All content below that line will be interpreted by Ruby|
Automatic Directory Indexes and Index Files
By default, our web server will display whatever files and folders you place in your web directory. You will be able to browse your files using this automatic directory index. To change this behavior for a specific directory add an index.html, index.php, or index.cgi file to that directory. Directories with files like that in them will not generate automatic directory indexes. Instead, they will display the content of your index file interpreted by php, cgi, or as html depending on the file extension used on your index file.
Preventing a Directory from being Served by Apache
You may come across the need to access content in your scripts that should not ever be served by Apache. You can prevent Apache from serving the content in a particular directory by denying access in a ".htaccess" file. Using your favorite text editor create a file named ".htaccess". The file should contain a single line that says "deny from all". Content from any folder with such a .htaccess file will not be served by Apache.