Fix ynhpanel.js access in unprotected case

[Josue-T]

Problem

To reproduce this bug you need this :

• Have to independant domain : by example :
  • a.tld (as the main yunohost domain)
  • b.tld
• Install an app on the "root" of b.tld wich use the "unprotected_uri" and which show the "Yunohost tile".
• Logon in sso on a.tld.
• Go on the app which is in b.tld/.
• See that you don't see the "Yunohost tile".

This happen because SSOwat don't detect any cookies for b.tld, so it considere the client as not authenticated.

Solution

Force SSOwat to reauthenticate the user for b.tld by a redirection. Note that process already work when the app is not installed in the root of the domain.

[alexAubin]

Wow that looks quite technical and must have been painful to debug x_x

Thanks a lot for this, I'll have a look at some point

[alexAubin]

I tested this today and it doesnt work 100% :/ ...

• In Firefox's debugger, I just see a 302 message for ynhpanel.js and somehow it doesn't really shows up ...
• but if I manually access ynhpanel.js then go back to that app ... then it's not a 302 anymore and the yunohost tile is effectively there ...
• (now that I think about it : maybe this is because my browser is set to refuse third party cookies ...)

Looking deeper in the code to understand the original issue, I realize that the way we handle multi-domain with the SSO is really confusing. In particular, for what I understand, one of the root cause of the issue is that we can't really check if the user is logged in when browsing b.tld because the cookie is hosted on a.tld ? But does it really makes sense that if the user is trying to access apps on b.tld they should log in a.tld ? Since those are two different unrelated domains (compared to say b.tld and sub.b.tld), why shouldn't we instead have two different login portals : b.tld and a.tld ...

Dunno if I'm stretching this too far but I opened a discussion on the forum : https://forum.yunohost.org/t/call-for-feedback-sso-portal-in-multi-domain-context-how-should-it-work/7491

[Josue-T]

Yes it's what I understood when I worked on this issue. Considering that the user is authenticated on a.tld and try to access in b.tld. The idea was this when a user try to access to an other domain.

• The user try to load the page b.tld.
• The browser load the the SSO code (css, js), because this code is some resources integrated in the page.
• The browser do request to b.tld/ynhpanel.js.
• The server redirect the browser to a.tld/sso/?r=HASH
• The server redirect the browser to b.tld/ynhpanel.js?sso_login=HASH
• The server redirect the browser to b.tld/ynhpanel.js
• Now the user is authenticated in b.tld.

[Josue-T]

Hello,

I did some new test and my conclusion is that it's not possible by this way. The initial idea was to do the "cross domain authentication" in the background of the browser. The problem with this is that the cookie stored by ssowat with the parameter SameSite=Lax. So any request done in the backgroud contains any cookie.

So the only way to fix this case of unprotected-url is to do a redirection in foreground as same as with the protected-url.

By example one idea could be to implement this mechanism:

• The user is authenticated in a.tld
• The browser make a request to b.tld in a unprotected url
• Call a javascript code which:
  • Save somewhere in the browser cache a value last_auth=TODAY
  • If last_auth > TODAY + 10hours and we don't have a valid SSOwAuthHash cookie:
    • Make a real redirection on a.tld on the foreground (to be able to send the cookie)
    • If the user is authenticated on a.tld:
      • Get by ssowat the CDA key and be redirected to b.tld
      • Do the authentication on b.tld with the CDA key and be redirected to the initial URL.
    • else:
      • Redirect the browser to the initial URL.

But yes it look like quite complex for not a big feature...

The other easy way is just to remove the SameSite=Lax. But it's quite bad about the security...