Hi,
We have RT set up behind a proxy ie.
<VirtualHost *:80>
ServerName rt.youramigo.com
…
ProxyPass / http://rtdb.bc.youramigo.com:8078/
After upgrading to 3.6.1 the redirect function in RT::Interface::Web
was exposing the internal URL rather than rt.youramigo.com.
A quick look through RT_Config.pm didn’t turn up anything that looked
appropriate so I made the following changes in our codebase which have
solved the problem here.
I’m sending the patch in case it’s useful for anyone else running RT
in this manner. Just set $UseCanonicalRedirect to 1 in
etc/RT_SiteConfig.pm
Cheers,
Michael Brader
— build/etc/RT_Config.pm 2006-08-18 01:34:39.000000000 +0000
+++ rt3/etc/RT_Config.pm 2006-08-18 04:00:50.000000000 +0000
@@ -344,6 +344,11 @@ Set($WebBaseURL , "http://localhost:$Web
Set($WebURL , $WebBaseURL . $WebPath . “/”);
+# If $UseCanonicalRedirect is true and the user is coming in via a
+# non-canonical hostname, redirect them to the canonical host,
+# Otherwise use $ENV{‘HTTP_HOST’} and $ENV{‘SERVER_PORT’}.
+Set( $UseCanonicalRedirect, 0 );
$WebImagesURL points to the base URL where RT can find its images.
Set($WebImagesURL , $WebPath . “/NoAuth/images/”);
— build/lib/RT/Interface/Web.pm 2006-07-25 23:44:13.000000000 +0000
+++ rt3/lib/RT/Interface/Web.pm 2006-08-18 04:01:03.000000000 +0000
@@ -187,14 +187,18 @@ sub Redirect {
my $uri = URI->new($redir_to);
my $server_uri = URI->new($RT::WebURL);
-
If the user is coming in via a non-canonical
-
hostname, don’t redirect them to the canonical host,
-
it will just upset them (and invalidate their credentials)
- if ($uri->host eq $server_uri->host &&
-
$uri->port eq $server_uri->port) {
-
$uri->host($ENV{'HTTP_HOST'});
-
$uri->port($ENV{'SERVER_PORT'});
-
}
-
unless ($RT::UseCanonicalRedirect) {
-
If the user is coming in via a non-canonical
-
hostname, don’t redirect them to the canonical host,
-
it will just upset them (and invalidate their credentials)
-
if ($uri->host eq $server_uri->host &&
-
$uri->port eq $server_uri->port) {
-
$uri->host($ENV{'HTTP_HOST'});
-
$uri->port($ENV{'SERVER_PORT'});
-
}
-
}
$HTML::Mason::Commands::m->redirect($uri->canonical);
$HTML::Mason::Commands::m->abort;
Michael Brader michael.brader@youramigo.com
Tony Cook writes:> On Fri, Aug 18, 2006 at 03:03:30PM +0930, Michael Brader wrote:
[…]
Another option that might work instead of a code change is
ProxyPassReverse:
<VirtualHost *:80>
ServerName rt.youramigo.com
…
ProxyPass / http://rtdb.bc.youramigo.com:8078/
ProxyPassReverse / http://rtdb.bc.youramigo.com:8078/
Thanks, that’s a very useful Apache directive I hadn’t come across
before.
Michael Brader michael.brader@youramigo.com
Hi,
We have RT set up behind a proxy ie.
<VirtualHost *:80>
ServerName rt.youramigo.com
…
ProxyPass / http://rtdb.bc.youramigo.com:8078/
After upgrading to 3.6.1 the redirect function in RT::Interface::Web
was exposing the internal URL rather than rt.youramigo.com.
Another option that might work instead of a code change is
ProxyPassReverse:
<VirtualHost *:80>
ServerName rt.youramigo.com
…
ProxyPass / http://rtdb.bc.youramigo.com:8078/
ProxyPassReverse / http://rtdb.bc.youramigo.com:8078/
(original bounced from list, resent with correct from.)
Tony
Good afternoon,
We have RT set up behind a proxy ie.
<VirtualHost *:80>
ServerName rt.youramigo.com
…
ProxyPass / http://rtdb.bc.youramigo.com:8078/
We have a similar setup (except we’re using mod_rewrite to setup the frontend
proxy) and I’m encountering the same problem.
I’m sending the patch in case it’s useful for anyone else running RT
in this manner. Just set $UseCanonicalRedirect to 1 in
etc/RT_SiteConfig.pm
Should I apply this patch to solve the problem, or is there some other
‘official’ method to solve it?
And Michael, thanks for making the patch available.
Thanks,
Charlie
Charlie Garrison garrison@zeta.org.au
PO Box 141, Windsor, NSW 2756, Australia
Charlie Garrison writes:
Good afternoon,
G’day.
We have RT set up behind a proxy ie.
<VirtualHost *:80>
ServerName rt.youramigo.com
…
ProxyPass / http://rtdb.bc.youramigo.com:8078/
We have a similar setup (except we’re using mod_rewrite to setup
the frontend proxy) and I’m encountering the same problem.
I’m sending the patch in case it’s useful for anyone else running RT
in this manner. Just set $UseCanonicalRedirect to 1 in
etc/RT_SiteConfig.pm
Should I apply this patch to solve the problem, or is there some
other ‘official’ method to solve it?
The official method which was pointed out after I sent in my patch is
to use ProxyPassReverse as follows:
ProxyPass / http://rtdb.bc.youramigo.com:8078/
ProxyPassReverse / http://rtdb.bc.youramigo.com:8078/
See one of:
http://httpd.apache.org/docs/1.3/mod/mod_proxy.html#proxypassreverse
http://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypassreverse
http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassreverse
depending on your version of Apache. I don’t know how to do
ProxyPassReverse with mod_rewrite, so you might want to use my patch.
And Michael, thanks for making the patch available.
No worries.
Michael Brader michael.brader@youramigo.com
Good morning,On 6/9/06 at 7:12 PM +0930, Michael Brader michael@youramigo.com wrote:
Charlie Garrison writes:
Should I apply this patch to solve the problem, or is there some
other ‘official’ method to solve it?
The official method which was pointed out after I sent in my patch is
to use ProxyPassReverse as follows:
ProxyPass / http://rtdb.bc.youramigo.com:8078/
ProxyPassReverse / http://rtdb.bc.youramigo.com:8078/
See one of:
http://httpd.apache.org/docs/1.3/mod/mod_proxy.html#proxypassreverse
mod_proxy - Apache HTTP Server
mod_proxy - Apache HTTP Server Version 2.2
depending on your version of Apache. I don’t know how to do
ProxyPassReverse with mod_rewrite, so you might want to use my patch.
According the documentation, I should just be able to use ProxyPassReverse. OK,
I was going to say it didn’t work but I just found my syntax error. That does
solve it.
It’s not an ideal solution though since requests can come from different domain
names (eg. either .com.au or .com) but at least I know what I need to do now to
fix it.
Thanks again for your help.
Charlie
Charlie Garrison garrison@zeta.org.au
PO Box 141, Windsor, NSW 2756, Australia