[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] {Disarmed} RE: {Disarmed} RE: SetLang - Use of the parameter referrer with the function view and the suffix .include

Thanks John,

Working fine. Furthermore, it?s also working when lang is defined only at the end of the original request, like:


Thanks again,


De : eprints-tech-bounces at ecs.soton.ac.uk [mailto:eprints-tech-bounces at ecs.soton.ac.uk] De la part de John Salter
Envoy? : 18 septembre 2014 09:53
? : 'eprints-tech at ecs.soton.ac.uk'
Objet : [EP-tech] {Disarmed} RE: SetLang - Use of the parameter referrer with the function view and the suffix .include

I don?t have any real experience of multi-language repositories, but I?ve just tested this on 3.3.12:
I added a line to perl_lib/EPrints/Apache/Rewrite.pm, where it is dealing with views.
my $filename = EPrints::Update::Views::update_view_file( $repository, $lang, $localpath, $uri );
print STDERR "LANG: $filename\n"; #added this line

When I visit (initially in ?en?) http://repo/view/creators/=C7alder=3AA=2E=3A=3A.include
it prints (in the Apache error log):
LANG: /eprints-3.3.12/archives/test/html/en/view/creators/=C7alder=3AA=2E=3A=3A.include

If I change the language (to ?fr?) in another browser window, and refresh the page, I get:
LANG: /eprints-3.3.12/archives/test/html/fr/view/creators/=C7alder=3AA=2E=3A=3A.include

- so it seems to work OK for direct requests.

If I try the ?set_lang? URL you sent, I think I see that same thing that you do ? but importantly, in the error log, there is nothing printed.
This makes me think that it?s a browser caching issue. It looks like the .include content is displayed from the browser cache ? and is in the wrong language.

If I try with a URL like (adding a query string to the referrer page):

The results seem to be OK ? as the query string on the referrer page has changed too.
Something could be added to perl_lib/EPrints/Plugin/Screen/SetLang.pm to try and force a reload ? but I?m not sure the best way of doing this - one suggestion is to add the parameter before the redirection at the end of ?sub from?:
                #if referrer has a query string, append langid as additional param, else add it as query
                $referrer .= ( m/\?/ ? '&' : '?' ) . "lang=$langid";
$self->{processor}->{redirect} = $referrer; #existing line

Have I understood your problem OK?
Does this look like it fixes it (I?m not sure if there will be any unwanted side effects of this alteration).


From: eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk> [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Jean-Pierre.Roy at etsmtl.ca<mailto:Jean-Pierre.Roy at etsmtl.ca>
Sent: 17 September 2014 16:23
To: eprints-tech at ecs.soton.ac.uk<mailto:eprints-tech at ecs.soton.ac.uk>
Subject: [EP-tech] SetLang - Use of the parameter referrer with the function view and the suffix .include

Hello All,

It sounds like that the cgi script "set_lang", with the parameter "referrer" and the function "view" ending with the suffix ".include", is generating, within the same web session, an output which is similar to the one you get when you send, again and again, the same input to a printer or a pdf creator : you get always the same result at the end.

Indeed, during the same web session, regardless of the time elapsed, the "set_lang" request, incorporating a ?view? with the suffix ?.include?, is always coming back with the same result, even if you try to change $langid with "set_lang?lang=xx" or to clear cookie when you send your request (like "MailScanner has detected a possible fraud attempt from "depository" claiming to be http://depository/cgi/set_lang?referrer=http://depository/view/people/{Family},_{Given Name}.include<http://depository/cgi/set_lang?referrer=http://depository/view/people/%7bFamily%7d,_%7bGiven%20Name%7d.include>" which normally returns a result based on the default language of the browser)

Would you please confirm whether this understanding is right or not?


Jean-Pierre Roy,
?cole de technologie sup?rieure,
Montr?al, Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20140918/7f616293/attachment-0001.html