Public link and language

[Crash--]

Today, when I create a public sharing link, the langage used seems to be the one of the owner of the sharing. The result is that if I'm french and I share a link to my VT colleague, they will have Drive in French. Not good.

Since today we don't have any mechanism to be able to know if i'm connected or not (yet), and what is my language settings, let's fallback to the browser langage if I'm not the owner of the sharing.

[Crash--]

Today the only way to know if we're the sharer is to make an http request. So we can do it, but it means that we need to find a way on how to wait before having this information before displaying anything.

We can't rely on cozyData.langage because we inject the langage of the instance in their. I'm not a big fan of changing that (not setting this langage attribute if I'm not the owner) because maybe it'll break few applications.

Maybe we can change the cozy-stack to inject isLoggedIn in cozy-data. Like that, if the user is not logged in, it means that we have to read the langage from the browser. If the user is logged in, then we take the langage from the instance (cozyData.langage).

@shepilov What do you think?

[shepilov]

The problem is that we don't know whether userB is logged in when we look at the shared page of userA. The session is bound to the userB domain. And stack nows nothing about.

Probably, until big changes with the unified drive and one session for the "whole" stack, the only common part is OIDC and user_info, so if we store lang claim, or I don't remember the standard name for it, we can retrieve it on client with OIDC cookie. But it will cost an extra auth round-trip before choosing language and a loading state or delayed render.

Maybe we can do something like an index for backchannel logout, but I'm not sure, we will need to change auth anyway on the client and server side

[Crash--]

This is why I’m saying « Since we don't have any mechanism to be able to know if i'm connected or not (yet) »

And this is why I want to fallback to browser’s langage in this case.

• if I’ve a session on the cozy, aka I’m the owner of the instance, we set the isLoggedIn flag to cozy data
• if I’m not logged in to this instance, aka I can be logged into my own cozy but not this one, then I fallback to the browser’s langage.

My main question here is about exposing this isLoogedIn flag to the cozy data instead of changing the already existing cozy data.langage.

And yes for the unified drive we need to be able to resolve correctly this issue by getting the right value (it’ll come from common settings and not from the sso)

[shepilov]

This is why I’m saying « Since we don't have any mechanism to be able to know if i'm connected or not (yet) »

And this is why I want to fallback to browser’s langage in this case.

• if I’ve a session on the cozy, aka I’m the owner of the instance, we set the isLoggedIn flag to cozy data
• if I’m not logged in to this instance, aka I can be logged into my own cozy but not this one, then I fallback to the browser’s langage.

My main question here is about exposing this isLoogedIn flag to the cozy data instead of changing the already existing cozy data.langage.

And yes for the unified drive we need to be able to resolve correctly this issue by getting the right value (it’ll come from common settings and not from the sso)

Oh, yes, if just ot add this flag for already logged in user looks straightforward and easy. I thought you wanted this flag no matter what cozy the user is logged in