💻 Use subdomains to navigate through languages

[jpelay]

Makes it possible to set the language through subdomains. In order to do this the following changes were made:

• Every route in the page was duplicated to include a subdomain argument, otherwise pages wouldn't be accesible without being prefixed with the subdomain.
• The set up language function was edited to take the subdomain as a parameter

Fixes #5720

How to test

In order to test this locally, we need to set an env variable that has a dot in it. The one I used was hedy.local, this name should be added to the hosts file in your system prefixed with the languages you want to test, for example

127.0.0.1 es.hedy.local hedy.local en.hedy.local

After doing this, before starting the server, you need to set the DOMAIN_NAME env variable export DOMAIN_NAME=hedy.local

After doing this you are set up to test the feature. You can navigate to nl.hedy.local:8080 and see that the language changes, and change it through the language selector. Also log in as a user, and change the preferred language there

[jpelay]

I'm figuring out how to share sessions between the different subdomains.

[jpelay]

I'm figuring out how to share sessions between the different subdomains.

Figured it out 😄

[jpelay]

@boryanagoncharenko This is done 😄 maybe you could take a look at this and check that it doesn't break anything!

[boryanagoncharenko]

There are 3 things, which seem off when I am testing locally with hedy.local set in the hosts file and as an env variable:

1. When I am at a subdomain, e.g. ar.hedy.local, and I login with an account that has a preferred language set to Bulgarian, the language of the profile gets changed to Arabic.
2. If I am still at ar.hedy.local, I am logged in and I try to change the language of the user profile (say, to Spanish), the language seems to be correctly selected in the drop-down, the page correctly reloads, but the subdomain is not changed so whole website still shows the content in the subdomain language, i.e. Arabic. If I reload the page, the language I selected is now reset to the subdomain language. So, effectively I have no means to change my profile language if I am within a specific subdomain.
3. When I log out, it seems that I only log out for the current subdomain. So if I have a session in the es.hedy.local, then I switch to en.hedy.local and log out, I might be under the impression that I have logged out, but navigating to the es.hedy.local shows me I am have not logged out. This might be a particular issue for environments in which users share computers:
   https://github.com/user-attachments/assets/962dc72e-32d4-4a7f-89fb-58e3e6453112

Ah, and one more thing, not so important. When I have the DOMAIN_NAME set to hedy.local, navigating to localhost fails because the langauge is present but its valid is "". We could change def before_route(endpoint, values): to check for that specific value and in this way we would support that too. Definitely not that important, though.

[boryanagoncharenko]

I think there is a typo: "<subdomaon>" should be "<language>"? Also, shouldn't there be a language="en" parameter to the exit_teacher_mode method?

[jpelay]

Good catch! Thank you so much

[boryanagoncharenko]

Thank you for the explanation and the changes.

Now, if I am in a specific language (en.hedy.local) and I log in with a user that has a different language preference (bg.hedy.local), I get redirected to the language of the user (bg.hedy.local). Also, when I change the language of the user and the page reloads, I land on the right domain (changing en to es redirects me to es.hedy.local).

However, I am still having an issue with the logout. Here are my steps:

• clear cookies, sessions, local storage, all of that
• go to bg.hedy.local and login with a user that uses bg as a language
• open en.hedy.local (directly changed in the webbrowser)
• open es.hedy.local (again, by changing the URL directly in the browser)
• logout
• click the browser's back button to go to en.hedy.local. At this point, I look as if I am logged in, but if I try to navigate to my-profile, I will be logged out.
• click the back button again (twice) to go to bg.hedy.local. Unfortunately, there I am logged in and I can access the account.

Here is a video:
https://github.com/user-attachments/assets/e559c935-d2c1-4444-94cf-ec8d2b8c5620

[jpelay]

Here is a video: https://github.com/user-attachments/assets/e559c935-d2c1-4444-94cf-ec8d2b8c5620

Yes, you're right, for some reason in the browser I was trying, things did work, but not in Firefox or Chrome. Can you try again? I think I fixed it. There's a problem though, apparently one can't set or unset the main domain cookie from a subdomain, thus, if I log out from en.hedy.local I'm still logged in in hedy.local, do you have any ideas on how we can do that? I think perhaps some sort of redirection would work, although that's ugly!

[jpelay]

@ZoomQuiet Hi!!! As you see we are still in the process of developing the subdomain rerouting, but we are working towards the goal we set a few weeks ago or making communities possible. Thank you for your patience!

[boryanagoncharenko]

Hey, I noticed a couple of things.

1. The session is shared between the main domain and the subdomains, so the sharing of cookies is working :)

2. When a user logs in, we set a token cookie (with name hedy). If the user does not have an active session, we try to login the user from this cookie i.e. check if the token in the cookie is still active in our DB see code here. When a user logs out, we remove the token from the DB, so that the user can no longer login with this token. In the PR we did not set the domain of the token cookie, which means that it only used for hedy.local. So, we successfully logout in the subdomain, but because this cookie is not sent from the subdomains, we do not delete it from the DB. And when we navigate back to hedy.local, the cookie is sent and bam! we are happily logged in again.

3. The flask docs do recommend changing the SESSION_COOKIE_NAME too or invalidating sessions.

4. The reason why Safari was acting out when we tested, is that it seems to be enforcing https under the hood. I will test how this behaves on alpha.

I added 1 small commit which updates the SESSION_COOKIE_NAME and sets the domain of the token cookie. This makes everything work on my end. Could you please check whether it works on yours too? Also, let me know what you think about the suggested changes.

[jpelay]

When a user logs in, we set a token cookie (with name hedy). If the user does not have an active session, we try to login the user from this cookie i.e. check if the token in the cookie is still active in our DB see code here. When a user logs out, we remove the token from the DB, so that the user can no longer login with this token. In the PR we did not set the domain of the token cookie, which means that it only used for hedy.local. So, we successfully logout in the subdomain, but because this cookie is not sent from the subdomains, we do not delete it from the DB. And when we navigate back to hedy.local, the cookie is sent and bam! we are happily logged in again.

Ahhh this makes a lot of sense! Thank you so much for looking into it you are the best.

I just tested a bit, and it does seems to be working!

[jpelay]

I kept testing and found some issues, one of them was a bug that wasn't introduced in this PR, so I opened an issue. The others were related to not adapting the routes correctly.

[jpelay]

I changed the behavior of the profile settings page. Now even if you force the language to change by changing the subdomain, if you enter in the profile settings page it will still show your preferred language