reverse_proxy 6.2.0

Posted October 22nd, 2010 by John Bickar

Download	Size	md5 hash
reverse_proxy-6.x-2.0.tar.gz	5.75 KB	e77f9b9dc86ecb8fb7ed86c2adc9d03e

Last updated: Fri, 10/22/2010 - 13:16

Please Note

Version 6.x-2.0 of this module is intended to be installed and enabled on fresh Drupal installs, ideally using the Collaboration Tools Installer. If you are using an earlier version of the Reverse Proxy Module on an existing site and it is working, you do not need to upgrade.

Summary

This module provides URL rewrites for integrating Drupal with a Reverse Proxy service. It was developed by the Stanford University Open Source Lab for integrating with the Virtual Host Proxy Service provided by Stanford University ITS (aka, "Vanity URL").

Caveats

There is no warranty, expressed nor implied, included with the Reverse Proxy module.

This module CAN SERIOUSLY BREAK YOUR SITE. Do not enable this for the first time on a live, production website. Best practices would dictate that you install and enable Reverse Proxy when your site is in early developmental stages.

Additionally, this module requires that your Drupal site be installed on Leland servers (i.e., in AFS space), as it relies on some custom commands for determining proxy information.

Configuration

The below instructions assume that you have /afs/ir/group/yourgroup/cgi-bin/drupal as your Drupal installation directory.

Go to http://vanityurl.stanford.edu to set up a virtual host proxy (e.g., https://yourgroup.stanford.edu) that points to your drupal directory: https://www.stanford.edu/group/yourgroup/cgi-bin/drupal
If you want to use the WebAuth module on your site (you do), you MUST request that the virtual host proxy use SSL (i.e., https://yourgroup.stanford.edu) in the "Additional Configuration" section.
Please pause here for a moment and be sure that you have read steps 1 and 2 carefully. If you want to use WebAuth, be sure you have specified https in all of your Vanity URL requests. When Reverse Proxy errors happen, this is usually the hill upon which they die.
In /afs/ir/group/yourgroup/cgi-bin/drupal/.htaccess, set the RewriteBase variable to /group/yourgroup/cgi-bin/drupal. (Note that this is set by default on sites installed with the Collaboration Tools Installer). The entire RewriteBase line in .htaccess should look like the following:
RewriteBase /group/yourgroup/cgi-bin/drupal
Download the Reverse Proxy module tarball from this page and extract it into your sites/all/modules directory (or wherever your contributed modules live).
Enable the Reverse Proxy module. NOTE: Simply enabling the module does not do anything immediately. You must go on to Step 6.
Go to admin/settings/reverse_proxy and verify that the information is correct. If it is, click "Save configuration". You will be redirected to https://yourgroup.stanford.edu/user, and you will need to log in again.
(optional) Create a .htaccess file in /afs/ir/group/yourgroup/WWW/ with the following directives:
RewriteEngine on
RewriteRule (.*) http://yourgroup.stanford.edu/$1 [R=301,L]
(Note: do not complete step 7 if you have files living in your WWW directory that you want to be accessible via the web.)

Reverse Proxy and Multiple Vanity URLs

Submitted on January 11th, 2011 by lmhopkin

In an instance where a department wants multiple vanity URLS (Undergraduate Academic Life is the case-in-point - "http://ual.stanford.edu" and "http://undergrad.stanford.edu") what is the proper use and configuration of the Reverse Proxy module? These two vanities are currently set up as redirects on the host server, but the department wants to have at lease one of them as a proper proxy pointing to "http://www.stanford.edu/dept/undergrad/cgi-bin/drupal_ual/". Since the site is live, we're reluctant to experiment without more certainty as to the outcome when we activate and configure the RP module.

Thanks,

Mike Hopkins

Issues

Submitted on December 13th, 2010 by bvb

Hi,

I enabled Reverse Proxy on the site I'm working on, following the instructions here. It appears to be working (that is, using the vanity URL goes where it's supposed to, and stuff displays with appropriate theme images), but with two issues:

1) Clean URLs: I can only get to ?q=admin and not /admin (/node/23, /admin, and the like return a 500). For now, I just turned off the Clean URLs setting, so stuff works but I have the annoying-looking ?q= all over the place.

2) WebAuth: I wrote a block to add a link to /webauth/... (the login link) as I'm not using the Drupal user system at all and this is cleaner (only club officers will be logging in, so I didn't want the big ugly login box). Loading it (from url.stanford.edu) logs me in but sends me to www.stanford.edu/group/.../drupal/?q=user instead of url.stanford.edu/?q=user, from which point the site is browsable but none of the configuration forms submit because they're all configured to submit to /admin, which goes to www.stanford.edu/admin when in the /group... site, instead of url.stanford.edu/admin.

My end goal is to have the entire site (both viewing and admin) available from url.stanford.edu, with login by WebAuth for for the ten or so people who will be adding content and administrating and preferably with the Clean URLs feature working. Any ideas on how to get there?

Thanks,
Ben

Update: Image nodes don't load theme and menu images.