Using https://
Drupal sites hosted at Stanford can benefit from using https:// protocol to secure communications between web server and client (this is a good thing). To do this, you need to set the $base_url variable to use an https:// address. Open settings.php (in sites/all/default) and change line 115 (as of Drupal 5.7) from:
# $base_url = 'http://www.example.com'; // NO trailing slash!to
$base_url = 'https://www.stanford.edu/group/groupname'; //NO trailing slash!
Note: you may have to change permissions on settings.php in order to edit it. It is usually set to read-only.
The Dreaded Internet Explorer Security Warnings
Unfortunately, as soon as you do this, IE might start popping up security warnings on every page saying, "This page contains both secure and nonsecure items. Would you like to display the nonsecure items?" (We'll leave the discussion as to why someone is using IE instead of one of multiple other browsers for a different day.)
The usual fix for this is to simply make sure that all resources that you are placing on your page are using https:// addresses. Drupal generally does a good job of this, because it tends to use relative paths rather than absolute paths. Changing $base_url automagically changes those paths to https. However, if you are linking to external images, scripts, or iframes, you'll need to either link to an https version of them, or copy them to your drupal installation directory and serve them over https. (Hyperlinks - <a href> tags - are OK.)
Two good ways to find these resources:- Click the broken lock icon in the Firefox address bar and then click the Media tab, it will tell you what resources are being served over an http:// connection.
- View the html source of the page and search for "http://" (no quotes)
Javascript Tools Module Bug
Update May, 2009: The latest version of Javascript Tools appears to have fixed this problem. The information below is retained for archive and troubleshooting purposes only.
If you are using the Javascript Tools module, there is a bug in one of the scripts that causes it to create an iframe without a src attribute. This problem is detailed in the project's issue queue, and the fix is below.
Here's a workaround, using a src="javascript:false;" fix.
BTW, this is a known bug in IE since at least version 4.
This solution does not re-pack the javascript, so you're adding an additional 8KB to the file size of your page (jquery.history_remote.pack.js = 8KB, jquery.history_remote.js=16KB)
- Dowload and unzip the jQuery History/Remote plugin
- Copy jquery.history_remote.js to the jstools/ directory (in sites/all/modules/ if that's where you installed it)
- Apply the history_remote.patch patch that's attached here. (Run it from the jstools/ directory.)
- Apply the tabs_1.patch patch that's attached here. (Run it from the jstools/tabs/ directory.)
- Profit?
Note: Thanks to Marco Wise for alerting us to this fun little bug and figuring out a fix.
