Infinite reload/loop when switching language with useKcLanguageTag

[Romcol]

Hi,

First, thank you for this very useful lib 🙏 !

I've experienced some infinite reload / loop on my keycloakify theme in specific cases.

To reproduce

• Go to login page
• Delete all cookies related to keycloak and local storage
• Switch language with selector

=> Infinite loop should happen at this point => error.ftl template should be reloaded infinitely
(or try again switching the language the other way around if it doesn't happen)

Probable issue

The locale as within the page is not the same as the one in local storage.

In this case the app keeps redirecting to kc_locale=fr but keycloak keeps returning the page in english.
=> If we remove this item in local storage the language switch is canceled and the page stays in english.

Do you have any idea how we could fix this?

Thanks 🙌

[garronej]

I can reproduce.

[garronej]

I think it will be an easy fix but I first need to be able to run a local container of keycloak to debug.
I just upgraded to an M1 Mac, it no longer works. Luckily the community have sorted it out already

[garronej]

It should be fixed in latest release, let me know if it did it.

[Romcol]

Hi,

Thanks for the fix but I doubt disabling the language switch on error.ftl is the way to go. I've seen it on other pages as well, it was just an example easy to reproduce, it will probably happen again. To me, the issue lies within useKcLanguageTag, I'll try to fix it myself or just stop using it.

Thanks anyways for checking,

[garronej]

Well, it's a bit more complex than it seems.
I know it looks like a quick and dirty fix but it isn't.
Now if you tell me you still got issues on other pages after trying with the latest release be sure, I will address it.

My fix doesn’t disable the language switch on the error.ftl page, it just prevent notifying Keycloak: "hey the user just changed language.
In fact, this block of code could be deleted and the language switch would still work (and even beter because we wouldn't have any reload).
We don’t need to reload the page to switch language we can do it fully client side, we only do the reload to let the Keycloak server know the user have switched language. If we don't tell it and the user switch language while registering (or because we detected the language of the browser is not the default Keycloak language), the locale claim in the JWT will always be the default Keycloak language.

Explanation of the infinite loop:

1. We ask to reload the same page but with a different language
2. The Keycloak server says: "No, you can't access this page" (In the reproduction path you offered it's because the cookies aren't present)
3. Keycloak sends us on the error.ftl page with the previous language, Keycloakify is expecting the language to have changed so goto 1).

By disabling to redirect on the error.ftl page, we prevent from looping.

It is the only scenario I see that can produce this loop.

Precisely, the loop happens when:
Given a i: number redirecting to kcContext.locale.supported[i].url returns a page where kcContext.local.current !== kcContext.locale.supported[i].currentLanguageTag
If you can exhibit another scenario where this is the case I will happily debug!

[Romcol]

Thank you for the comprehensive explanation @garronej!

Indeed, the language switch doesn't work on error.ftl, even with the default theme so there's no better solution.
The only issue I see is when you allow language switch on this page for the client, you end up having two different languages on the same page, the client being translated to the language your requested but with the inner messages in the previous language. I'm actually not sure if there's a real benefit in changing the language in the client instead of redirecting to the page directly.

I found as well that the same issue is present at least in these pages: info.ftl, login-page-expired.ftl.
It's better to disable the language switch on these templates and make sure it can't trigger an infinite loop.

Cheers,

[garronej]

you end up having two different languages on the same page

Nice catch, I will address that.

I'm actually not sure if there's a real benefit in changing the language in the client

As a matter of fact, with Keycloakify the pages served by the Keycloak server are static, there is just the kcContext that is generated dynamically on the backend so the frontend is in charge of everything.
That said, I agree that we could come up with a less convoluted implementation of useMessage.

I found as well that the same issue is present at least in these pages: info.ftl, login-page-expired.ftl.

very helpful thank you

[Romcol]

Thank you, the fix seems to work ! I will keep you on the loop if we find other templates causing such issues :)

[garronej]

I just to let you know that I have re-writen i18n.
It's much more straight forward now.