[Evergreen-general] Evergreen 3.11.0a not properly switching into Czech in the staff client

[Linda Jansová]

Hi Jason and others,

Given your hint that the heart of the issue might lie in the eg to eg2 
transitions, we did some more tests which have led us to the following 
observations:

After logging in (at /eg/staff) one gets redirected to 
/eg2/en-US/staff/admin/workstation/workstations/manage.

I am not sure whether it is important or not (well, maybe not) but I 
have found one hardcoded occurrence of this part of URL in the code:

https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=%2Feg2%2Fen-US%2Fstaff%2Fadmin%2Fworkstation%2Fworkstations%2Fmanage 
<https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=%2Feg2%2Fen-US%2Fstaff%2Fadmin%2Fworkstation%2Fworkstations%2Fmanage>

There are also a couple of other cases where a URL with /eg2/en-US is 
being explicitly used:

https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=%2Feg2%2Fen-US%2F 
<https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=%2Feg2%2Fen-US%2F>

(Perhaps there are some more when the URL is combined from smaller 
chunks of text and so it is not that easy to spot the places where these 
might pop up.)

Getting back to the logging in process: when being at 
/eg2/en-US/staff/admin/workstation/workstations/manage, we have noticed 
the following error:

/eg/staff/t_splash (Error: [$compile:tpload] Failed to load template: 
./t_splash (HTTP status: -1 )

https://errors.angularjs.org/1.6.10/$compile/tpload?p0=.%2Ft_splash&p1=-1&p2 
<https://errors.angularjs.org/1.6.10/$compile/tpload?p0=.%2Ft_splash&p1=-1&p2>=)

When we tried to go to /eg/staff/t_splash in the browser, we actually 
saw the webpage (even correctly translated to Czech, especially after 
letting the browser repair encoding as this was actually just a part of 
a HTML page beginning with <div class="container">). So it seems to be 
there...

We also tried to have a closer look at our eg_vhost.conf. In it we have 
both Czech and English enabled:

# cs-CZ

RewriteCond %{REQUEST_URI} ^/eg2/

RewriteCond %{REQUEST_URI} !^/eg2/cs-CZ/

RewriteCond %{HTTP_COOKIE} eg_locale=cs_cz

RewriteRule ^/eg2/(.*) https://%{HTTP_HOST}/eg2/cs-CZ/$1 [NE,R=307,L]


# Default / en-US.

# No alternate supported cookie provided.

RewriteCond %{REQUEST_URI} ^/eg2/

RewriteCond %{REQUEST_URI} !^/eg2/([a-z]{2}-[A-Z]{2})/

RewriteRule ^/eg2/(.*) https://%{HTTP_HOST}/eg2/en-US/$1 [NE,R=307,L]

When we tried to disable the English part of it, we saw 404s in our 
staff client. So this is definitely not a way to go (although – in 
theory – if this worked, we would probably be quite happy living with 
Czech as the only language for our staff client interface).

I was also thinking that perhaps the eg_vhost.conf may include some 
rewrites to cover the cases of switching between eg and eg2 but couldn’t 
locate any. So this logic is probably described somewhere else...

Although we are most likely on the wrong track, I thought it might be 
useful to share our findings anyway (if not anything else, then perhaps 
it could to help narrow down the search scope)…

Linda


On 6/20/23 22:35, Linda Jansová wrote:
> Hi Jason,
>
> Thank you very much for looking into this!
>
> Perhaps it may be useful - especially now that it seems that the 
> cookies are not to blame for this :-) - to mention that we are on 
> Ubuntu 20.04 LTS and the latest OpenSRF tarball has been used.
>
> If there is any other piece of information that might be useful, we 
> will be more than happy to provide it.
>
> Linda
>
> On 6/20/23 22:10, Jason Boyer wrote:
>> Hi Linda. I've looked at this a bit today and can say that it 
>> shouldn't have anything to do with that cookie message. It seems like 
>> the transition between the Angular (/eg2/) and AngularJS (/eg/) sides 
>> of the client doesn't work correctly, but I do see in the browser 
>> console "Applying locale cs-CZ" so the cookie is arriving and being 
>> parsed as expected, but for some reason isn't taking effect. I'll 
>> keep looking but wanted to let you know that I do at least have an 
>> idea what it *isn't*. :)
>>
>> Jason
>>
>> -- 
>> Jason Boyer
>> Senior System Administrator
>> Equinox Open Library Initiative
>> JBoyer at equinoxOLI.org
>> +1 (877) Open-ILS (673-6457)
>> https://equinoxOLI.org/
>>
>>> On Jun 19, 2023, at 8:30 AM, Linda Jansová via Evergreen-general 
>>> <evergreen-general at list.evergreen-ils.org> wrote:
>>>
>>> Dear all,
>>>
>>> We have just installed Evergreen 3.11.0a (it is a fresh install from 
>>> the tarball) and have proceeded to setting up Czech as a language to 
>>> be used not only in the Bootstrap OPAC but also in the staff client.
>>>
>>> However, it seems that the staff client does not reliably keep Czech 
>>> as the interface language beyond the login screen.
>>>
>>> After logging into the staff client (with the original login screen 
>>> being in Czech), a browser developer tool in Firefox says that "Some 
>>> cookies are misusing the recommended “SameSite“ attribute" (the 
>>> attached screenshot provides the same information in a visual format).
>>>
>>> There is a link that provides more information on the nature of the 
>>> attribute:
>>>
>>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value
>>>
>>> It appears that eg.auth.token and eg.auth.time do not provide a 
>>> valid value for the aforementioned SameSite attribute, meaning that 
>>> Lax (as a fallback value) is used instead. This, according to 
>>> Mozilla.org, "Means that the cookie is not sent on cross-site 
>>> requests, such as on requests to load images or frames, but is sent 
>>> when a user is navigating to the origin site from an external site 
>>> (for example, when following a link). This is the default behavior 
>>> if the |SameSite| attribute is not specified."
>>>
>>> Could that be a reason why the staff client does not honor the 
>>> selected locale and keeps changing things from Czech to English (and 
>>> sometimes also vice versa)?
>>>
>>> If so, do you have any idea how to properly fix it?
>>>
>>> If not, where else should we look?
>>>
>>> I am also attaching our eg_vhost.conf with our current setup.
>>>
>>> Thank you very much for any kind of help provided!
>>>
>>> Linda
>>>
>>> <eg_vhost.conf><Screenshot at 2023-06-19 
>>> 14-05-14.png>_______________________________________________
>>> Evergreen-general mailing list
>>> Evergreen-general at list.evergreen-ils.org
>>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-general/attachments/20230622/42a0ae7f/attachment.htm>