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
jbo...@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@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@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
_______________________________________________
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general