Whilst looking at an item detail page on the OPAC (opac-detail.pl) you are redirected back to the OPAC homepage instead of staying on opac-detail. The language is successfully changed. This is not an issue on master. We have tested it on 16.11, am not sure if it is an issue anywhere inbetween.
I cannot reproduce this problem in 16.11.15.
Hm, still seeing it in our 16.11.15 installation. How did you test? 1) Select English 2) Do a search in the OPAC 3) Switch language 4) You are returned to the start page instead of remaining on the result list
Also happens in 17.11
This seems to work alright in my devbox on master. Could someone confirm for 18.05?
Still happen on 18.05, very annoying. Not only on search result (opac-search.pl) but anywhere on OPAC, even on user account (opac-user.pl). Maybe language should be part of the URL query using ISO 639-1 language code: ?hl=en.
(In reply to Katrin Fischer from comment #4) > This seems to work alright in my devbox on master. Could someone confirm for > 18.05? The bug can be reproduced on 16.11, but on master too. Depends on factors as using https and Plack. If you use both Plack and https (which you normally should), you should be able to reproduce it.
Created attachment 77323 [details] [review] Bug 19799: Add localReferer function to module, and test Before implementing the change in opac-changelanguage, we define a new function (in Koha/Util.pm) and add tests. Test plan: Run t/Koha/Util/localReferer.t Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 77324 [details] [review] Bug 19799: Introduce localReferer in opac-changelanguage.pl Nice and easy replace.. Test plan: Test changing language from various OPAC locations. (Verify that you are not redirected to the home page.) Include language=[some_language] in the URL before changing language. [Bonus] Test calling opac-changelanguage.pl from another server. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Caused by bug 18946 on 17.11 and backported
This might help you understand the problem: From C4/Auth: # 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; If you call CGI->url under Plack, you will get http back which is obviously wrong if you used https.
The right way to make things work with our codebase is to uncomment the following line in both apache-shared-intranet-plack.conf and apache-shared-opac-plack.conf. # RequestHeader set X-FORWARDED-PROTO "https" This header would be used by Plack::Middleware::ReverseProxy to make $cgi->https work correctly [1] The problem with that is we didn't manage to automate it for non-tech users. That's an area we could spend time on! The approach I aimed for having time to implement, was to split like this: OPACBaseURL => OPACProto (http/https/gopher) + OPACDomainName + OPACBasePath (/cgi-bin/koha, preparing the ground for removing the requirement to use that path). The problem with this is that we of course allow different domains to be used (a feature). If we were to add code that workarounds the issue on the codebase, I think we should better add it as a Plack middleware as we did in Koha::Middleware::SetEnv. [1] https://github.com/plack/Plack/wiki/How-to-detect-reverse-proxy-and-SSL-frontend
This report needs a staff counterpart.
We tested the solution Tomas suggested and it works well!
We've also tested this line, but only with https: RequestHeader set X_FORWARDED_PROTO "https" env=HTTPS Maybe this could be a general solution? https://httpd.apache.org/docs/2.4/mod/mod_headers.html#requestheader The RequestHeader directive may be followed by an additional argument, which may be any of: early Specifies early processing. env=[!]varname The directive is applied if and only if the environment variable varname exists. A ! in front of varname reverses the test, so the directive applies only if varname is unset.
Tested 'RequestHeader set X_FORWARDED_PROTO "https" env=HTTPS' with http and https, everthing seemed to be ok.
(In reply to Ulrich Kleiber from comment #15) > Tested 'RequestHeader set X_FORWARDED_PROTO "https" env=HTTPS' with http and > https, everthing seemed to be ok. Uli, the solution requires SSLOptions +StdEnvVars which I'm not sure is enabled by default. Did you have to tweak it yourself? What OS/version are you on? https://httpd.apache.org/docs/2.4/mod/mod_ssl.html
Tomás, we are on debian jessie. 'SSLOptions +StdEnvVars' is only set in default-ssl.conf, but this site is not enabled. It looks like it is enabled by default. /etc$ sudo grep -R StdEnvVars * apache2/sites-available/default-ssl.conf: # o StdEnvVars: apache2/sites-available/default-ssl.conf: SSLOptions +StdEnvVars apache2/sites-available/default-ssl.conf: SSLOptions +StdEnvVars
Tomás, I think the mod_rewrite module is responsible for the setting of 'SSLOptions +StdEnvVars'. It is required for the RewriteCond Directive. https://httpd.apache.org/docs/current/mod/mod_rewrite.html ...These variables are available even without setting the StdEnvVars option of the SSLOptions directive... Using 'RequestHeader set X_FORWARDED_PROTO "https" env=HTTPS' with Koha shoudln't be a problem.
(In reply to Ulrich Kleiber from comment #18) > Tomás, I think the mod_rewrite module is responsible for the setting of > 'SSLOptions +StdEnvVars'. It is required for the RewriteCond Directive. > > https://httpd.apache.org/docs/current/mod/mod_rewrite.html > ...These variables are available even without setting the StdEnvVars option > of the SSLOptions directive... > > Using 'RequestHeader set X_FORWARDED_PROTO "https" env=HTTPS' with Koha > shoudln't be a problem. Awesome, Uli. I propose we file a new bug for setting what you propose, and we keep this one for Marcel's enhancement which is still a nice improvement.
Fixed by the X-FORWARDED-PROTO approach on bug 21267. Will resubmit the referer code under a new enhancement.
So interesting seeing the history of Bug 21267!