Portal button is not showing in many apps

[eauchat]

I still don't understand where this is coming from, but in some apps the portal button (the one that toggles the display of the panel) is not shown. I didn't make much investigation yet, but it seems to happen with rainloop and ampache at least, also with opensondage and wordpress (but maybe for those last two it could be by design because they are public?).

[kay0u]

ampache: https://github.com/YunoHost-Apps/ampache_ynh/blob/master/conf/nginx.conf#L52

wordpress: https://github.com/YunoHost-Apps/wordpress_ynh/blob/master/conf/nginx.conf#L30 (I didn't see in the script if it is removed)

Maybe the package_check should handle these lines?

[maniackcrudelis]

It is for wordpress kay0u, but the last PR fixes that.

[Psycojoker]

Is this one fixed now?

[alexAubin]

Hm I think it's now in the level 8 requirements ? My understanding is that it's up to each app package to include the corresponding conf snippet (if relevant), can't really have a general fix... So I would vote to close this issue

[eauchat]

I'm not 100% sure the following is related to this issue, but I just noticed that on nextcloud and rainloop (at least) lots of errors were logged in the browser console:

The resource from “https://cloud.domain.tldynhtheme/ynh_portal.js” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
The resource from “https://cloud.domain.tldynhtheme/custom_overlay.css” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
The resource from “https://cloud.domain.tldynhtheme/ynh_overlay.css” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
The resource from “https://cloud.domain.tldynhtheme/custom_portal.js” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).

Seems to me that this is not a problem of each app but of sso no serving files properly. No?

[alexAubin]

Hmyea sounds like that could be related ?

I think the relevant pieces of code are

https://github.com/YunoHost/SSOwat/blob/stretch-unstable/access.lua#L354-L355

and

https://github.com/YunoHost/SSOwat/blob/stretch-unstable/helpers.lua#L564-L588

But I don't understand why the MIME type would end up being text/html ... Or maybe that's something happening in the nginx conf ...

[eauchat]

Ok, I was looking into the issue and I think I understood where the mimetype problem comes from in fact. The problem is that the file is actually not found and the url "https://cloud.domain.tld/ynhtheme/custom_portal.js" is actually answering with 404. It seems that the files ynh_portal.js, ynhtheme/custom_portal.js... are only served in the domain of the sso, and not in other domains (like cloud.domain.tld or any app specific domain).

[eauchat]

I managed to solve the issue on my instance using the reverse proxy of the main machine that's before the ynh VM (so not within yunohost).

I just created redirection for all domains to the domain where the sso is located (in the following list, as an example, the sso is served at sso.domain.tld). The elements that I needed to redirect were:

/ynh_portal.js                   => sso.domain.tld/ynh_portal.js
/ynhtheme/custom_portal.js       => sso.domain.tld/ynhtheme/custom_portal.js
/ynh_overlay.css                 => sso.domain.tld/ynh_overlay.css
/ynhtheme/custom_overlay.css     => sso.domain.tld/ynhtheme/custom_overlay.css
/yunohost/sso/portal.html        => sso.domain.tld/yunohost/sso/portal.html

It was quite easy to do with templates (at least in my setup). Maybe it could be an easy approach for yunohost, using some nginx rules that redirect to the proper url where the sso elements are located. But it's a hack on the existing system, and there are probably better designs for the sso that could allow to avoid that. Maybe it can be a good temporary approach still. Don't know.

I could try to implement it at some point, but probably not any time soon because I don't have a working development environment, and it will take me some time to have one again.

[scharc]

Having the problem in gitlab. See here: https://github.com/YunoHost-Apps/gitlab_ynh/issues/91

[alexAubin]

Closing because we're going to drop the tile thing entirely in the SSOwat/portal-api refactoring