http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=8766, | |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=2152 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 --- Comment #1 from David Cook <dcook@prosentient.com.au> --- Created attachment 24556 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=24556&action=edit Bug 11575 - OPACBaseURL sometimes set by ENV variable and not system preference This patch changes how the OPACBaseURL parameter gets set in the subroutine get_template_and_user in Auth.pm. Currently, it's being set by the $ENV{'SERVER_NAME'} variable, which is typically filled by the URL that the user uses to access a page. While this works in many cases, this causes a problem when using a proxy server. The SERVER_NAME will instead be the domain of the proxy server (for more info, read the comments already on this bug on Bugzilla). There are ways to compensate for proxy servers. However, such a solution seems a bit convoluted... Elsewhere in Koha, we use the system preference OPACBaseURL, so I think it makes sense to use it here as well. I did leave the $ENV{'SERVER_NAME'} as a full back if OPACBaseURL isn't set, but that's it. _TEST PLAN_ Before applying: 1) Clear your OPACBaseURL preference 2) Perform a search in the OPAC 3) Click on or hover over the orange RSS icon 4) Note that the URL you used to access the site is the URL used for the RSS link 5) Add an OPACBaseURL that isn't the same as the actual OPAC URL 6) Note that the OPACBaseURL system preference has no effect here After applying the patch: 7) Refresh the page 8) Note that the URL you see now is actually the OPACBaseURL system preference that you set 9) Clear your OPACBaseURL system preference 10) Refresh your search page 11) Note that the URL has reverted back to the URL that you used to access the page -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mtompset@hotmail.com --- Comment #2 from M. Tompsett <mtompset@hotmail.com> --- HTTP_X_FORWARDED_HOST That reminds me of bug 6800. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 M. Tompsett <mtompset@hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #24556|0 |1 is obsolete| | --- Comment #3 from M. Tompsett <mtompset@hotmail.com> --- Created attachment 25601 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25601&action=edit [SIGNED OFF] Bug 11575 - OPACBaseURL sometimes set by ENV variable and not system preference This patch changes how the OPACBaseURL parameter gets set in the subroutine get_template_and_user in Auth.pm. Currently, it's being set by the $ENV{'SERVER_NAME'} variable, which is typically filled by the URL that the user uses to access a page. While this works in many cases, this causes a problem when using a proxy server. The SERVER_NAME will instead be the domain of the proxy server (for more info, read the comments already on this bug on Bugzilla). There are ways to compensate for proxy servers. However, such a solution seems a bit convoluted... Elsewhere in Koha, we use the system preference OPACBaseURL, so I think it makes sense to use it here as well. I did leave the $ENV{'SERVER_NAME'} as a full back if OPACBaseURL isn't set, but that's it. _TEST PLAN_ Before applying: 1) Clear your OPACBaseURL preference 2) Perform a search in the OPAC 3) Click on or hover over the orange RSS icon 4) Note that the URL you used to access the site is the URL used for the RSS link 5) Add an OPACBaseURL that isn't the same as the actual OPAC URL 6) Note that the OPACBaseURL system preference has no effect here After applying the patch: 7) Refresh the page 8) Note that the URL you see now is actually the OPACBaseURL system preference that you set 9) Clear your OPACBaseURL system preference 10) Refresh your search page 11) Note that the URL has reverted back to the URL that you used to access the page Followed test plan, worked as expected. I have my apache redirecting HTTP to HTTPS, and put my IP address in URL which did trigger the OPAC as expected. The IP address was in the RSS link as the test predicted after the patch. HTTPS in both cases. Signed-off-by: Mark Tompsett <mtompset@hotmail.com> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 --- Comment #5 from M. Tompsett <mtompset@hotmail.com> --- Good point, Marcel. The third patch on bug 8952 has this: # Set the using_https variable for templates # FIXME Under Plack the CGI->https method always returns 'OFF' my $https = $in->{query}->https(); my $using_https = (defined $https and $https ne 'OFF') ? 1 : 0; I think perhaps this patch should use this variable ($using_https) instead of checking $in->{query}->https() itself, and add a depends to the bug. -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=5010 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 --- Comment #7 from David Cook <dcook@prosentient.com.au> --- Thought about switching this back to Signed Off, but made minor changes to take into account bug 8952, so leaving that up to M. Tompsett and/or the QA team. (Also improved the commit message to be more accurate) -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #25601|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |8952 -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #28857|0 |1 is obsolete| | --- Comment #10 from Chris Cormack <chris@bigballofwax.co.nz> --- Created attachment 28987 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=28987&action=edit Bug 11575 - OPACBaseURL sometimes set by ENV variable and not system preference This patch changes how the OPACBaseURL parameter gets set in the subroutine get_template_and_user in Auth.pm. Currently, it's being set by the $ENV{'SERVER_NAME'} variable. In many cases, this will probably match the URL that the user uses to access a page. However, this causes problems with reverse proxies. There are ways to compensate for proxy servers (such as inspecting other variables set by the web server), but such a solution seems a bit convoluted...especially since we already use the system preference OPACBaseURL in many other parts of Koha. We probably shouldn't be passing OPACBaseURL from Auth.pm at all, and instead use the Koha TT plugin and using_https param to determine protocol. However, that's outside the scope of this bug/patch. This patch is just meant to fix an existing bug. I did leave the $ENV{'SERVER_NAME'} as a full back if OPACBaseURL isn't set, but that's it. _TEST PLAN_ Before applying: 1) Clear your OPACBaseURL preference 2) Perform a search in the OPAC 3) Click on or hover over the orange RSS icon 4) Note that the URL used for the RSS links is either: a) The same URL you used to access Koha (no reverse proxy) b) The ServerName from your Koha apache conf which isn't the same URL you used to access Koha (reverse proxy) 5) Add an OPACBaseURL that isn't the same as the actual OPAC URL 6) Note that the OPACBaseURL system preference has no effect here After applying the patch: 7) Refresh the page 8) Note that the URL you see now is actually the OPACBaseURL system preference that you set 9) Clear your OPACBaseURL system preference 10) Refresh your search page 11) Note that the URL has reverted back to the URL that you saw before (either the original Koha site URL or the Koha ServerName defined in Apache and not the URL of the proxy) Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz> -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 --- Comment #12 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #11)

Created attachment 29101 [details] [review] Bug 11575 - OPACBaseURL sometimes set by ENV variable and not system preference

This patch changes how the OPACBaseURL parameter gets set in the subroutine get_template_and_user in Auth.pm.

Currently, it's being set by the $ENV{'SERVER_NAME'} variable. In many cases, this will probably match the URL that the user uses to access a page. However, this causes problems with reverse proxies.

There are ways to compensate for proxy servers (such as inspecting other variables set by the web server), but such a solution seems a bit convoluted...especially since we already use the system preference OPACBaseURL in many other parts of Koha.

We probably shouldn't be passing OPACBaseURL from Auth.pm at all, and instead use the Koha TT plugin and using_https param to determine protocol. However, that's outside the scope of this bug/patch.

This patch is just meant to fix an existing bug.

I did leave the $ENV{'SERVER_NAME'} as a full back if OPACBaseURL isn't set, but that's it.

_TEST PLAN_

Before applying:

1) Clear your OPACBaseURL preference 2) Perform a search in the OPAC 3) Click on or hover over the orange RSS icon 4) Note that the URL used for the RSS links is either: a) The same URL you used to access Koha (no reverse proxy) b) The ServerName from your Koha apache conf which isn't the same URL you used to access Koha (reverse proxy) 5) Add an OPACBaseURL that isn't the same as the actual OPAC URL 6) Note that the OPACBaseURL system preference has no effect here

After applying the patch:

7) Refresh the page 8) Note that the URL you see now is actually the OPACBaseURL system preference that you set 9) Clear your OPACBaseURL system preference 10) Refresh your search page 11) Note that the URL has reverted back to the URL that you saw before (either the original Koha site URL or the Koha ServerName defined in Apache and not the URL of the proxy)

Signed-off-by: Chris Cormack <chris@bigballofwax.co.nz>

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>

Should this be marked as Passed QA now? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com --- Comment #14 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Are we introducing problems for Plack? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 --- Comment #16 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi from comment #14)

Are we introducing problems for Plack?

I don't think so. Rather, we're highlighting an existing problem that Marcel noted in bug 8952. (Marcel added the FIXME in bug 8952 and I'm just copying it over to some relevant areas.) I imagine that most people are using proxies in front of Plack so this might be relevant for fixing this issue: https://github.com/plack/Plack/wiki/How-to-detect-reverse-proxy-and-SSL-fron... Plack::Middleware::ReverseProxy seems to just reset environmental variables depending on the headers it gets from the reverse proxy (so long as they're configured). http://cpansearch.perl.org/src/MIYAGAWA/Plack-Middleware-ReverseProxy-0.15/l... I suppose another alternative might be just to set the environmental variable explicitly in the vhost (if you're using Apache) or whatever else you need to with another proxy. This may or may not be relevant: http://httpd.apache.org/docs/2.2/mod/mod_ssl.html We don't use Apache for our proxy server, so I'm not really sure, but this info might give other people (who are using Plack and a front end proxy) some ideas. I haven't played with Plack yet but I've done a fair bit of reading. By the way, here is the CGI->https() method from 5.16: #### Method: https # Return the value of HTTPS, or # the value of an HTTPS variable, or # the list of variables #### 'https' => <<'END_OF_FUNC', sub https { my ($self,$parameter) = self_or_CGI(@_); if ( defined($parameter) ) { $parameter =~ tr/-a-z/_A-Z/; if ( $parameter =~ /^HTTPS(?:_|$)/ ) { return $ENV{$parameter}; } return $ENV{"HTTPS_$parameter"}; } return wantarray ? grep { /^HTTPS(?:_|$)/ } keys %ENV : $ENV{'HTTPS'}; } END_OF_FUNC It looks like it's just looking for a HTTPS environmental variable, which Plack::Middleware::ReverseProxy can provide. Otherwise, I suppose it depends on how you've configured Plack? -- You are receiving this mail because: You are watching all bug changes.

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11575 --- Comment #18 from M. Tompsett <mtompset@hotmail.com> --- (In reply to Robin Sheat from comment #15)

(In reply to Tomás Cohen Arazi from comment #14)

...

Are we introducing problems for Plack?

Probably not. Really, OPACBaseURL should include the method so there's no need for any of that $using_https crap. But that's a story for another day.

Also, as this promotes the use of the syspref over the envvar, it's probably better for plack.

What's even better for Plack is using the OPACBaseURL with the protocol included all the time, like I just tweaked the code for in bug 5010. ;) Well, to be honest, I don't know if it is better for plack, but that using_https stuff is reduced a bit now. :) -- You are receiving this mail because: You are watching all bug changes.