YunoHost 3.7 spooky testing / Call for feedback

Pretty much everything is backward compatible, so basically all install and other scripts will keep working as they do right now (modulo depreciationg warning), and if they don’t then that’s a bug that should be fixed.

As far as I remember, the only not-backward compatible thing is the use of protected uris, in the sense that even when being logged-in you still won’t have access to the protected uris (so that’s kinda conservative). The affected apps are apparently : lstu, lufi, dotclear, lektor, bozon, and lutim.

Admin panels are expected to be handled by a specific permission. Typically you would define such a permission with something like :

ynh_permission_create --permission "admin" --url "/admin" --allowed "$admin_user"

which controls accesses to https://domain.tld/app/admin. Then the instance’s admin can add/remove accesses to this permission from the webadmin interface, just like it does for the main permission which controls access to /app. (Also, if I remember correctly, a user has to be authorized for /app/ to be able to access /app/admin.)

Not sure what you’re thinking about, but right now it’s “just” about : going into Users > Manage permissions and groups, then adding / removing the permission to the ‘Visitors’ group and that’s it. Then visitors will be able to access (or not) to /app (but not to /app/admin if it’s controlled through a diferent permission)

There have been test batches using the unstable CI to validate that there was no regression (at least from the CI point of view) though I didn’t re-ran a batch of test following the release of the testing and the next iterations of fixes

What I’m thinking about is that kind of thing:

That’s not obvious (my bad by the way) but here the idea is to have the links always publicly available, but not the main page of jirafeau nor its admin panel.

It would translate as 3 different permissions. But an user willing to turn the app public or private shouldn’t have to play with those 3 different permissions and know which one should be private or not.
An user that want to turn the app public or private should be able to simply ask for it, without having to know how it should work. And that exactly the purpose of the actions public_private.

Jirafeau is only one example of those permissions.
We have also that kind of situation for API for mobile apps.

Those situations are what I’m thinking about when I say that apps are going to break. The CI can’t test those things.

Again, I’m not saying that all that permission system is a bad thing, but packagers should have a proper warning and a clear explanation before that testing is released.

I quickly read the install script of all our apps tagged as “working”.

Among them, here a list of the ones which are doing non trivial things with the old permission system (not only a simple protect “/”):



























I may miss some of them.
I added those that are doing something like yunohost app addaccess $app -u $admin because I was not sure if it can be a problem with the new permission system.

A new testing version has been released, which includes some important fixes:

:hammer_and_wrench: Detailed changelog

  • [fix] Match undefined function (SSOwat#151)
  • [fix] Cohabitation between the old and the new permission system (SSOwat#156)
  • [fix] Slapd may crash if we try to update the LDAP with no change (Moulinette#231)
  • [fix] Permission url (YunoHost#871)
  • [fix] DNS resolver (YunoHost#859)
  • [fix] Legacy permission management (YunoHost#868, YunoHost#855)
  • [enh] More informations in hooks permission (YunoHost#877)
  • [i18n] Improved translations for French, Basque, Hindi, Turkish, Bengali (Bangladesh), Arabic, Hungarian, Polish, Catalan, Dutch, Portuguese, Italian, German, Swedish, Russian, Esperanto, Occitan, Nepali

Thanks so much to all the contributors :heart: ! (Aleks, amirale qt, Bram, ButterflyOfFire, elie gavoty, Filip Bengtsson, Josué, Kay0u, ljf, Maniack, Quenti, xaloc33)

5 Likes

Bonsoir,

Dans le cadre du passage de Stretch à Buster, faudra-t’il passer par un mise à niveau de YunoHost 3.6.x à 3.7.x préalablement à la migration ?

ppr

Bonjour,

Rien n’est encore fixé il me semble, mais de toute façon il vaut mieux (si ce n’est pas obligatoire?) être à la version la plus à jour avant de faire la migration.

Nous prévoyons encore une 3.8 avant le passage à la 4.0 (Buster) afin de préparer le terrain.

Bonjour,

Merci pour ces informations.
La version stable actuelle est 3.6.x.
Est-ce que la 3.7.x testing va bientôt passer en stable ?
On verra pour la 3.8.x après avant la migration vers la 4.0.x :wink:

ppr

Nous attendons des retours ainsi que l’intégration continue des apps en testing pour passer la 3.7 en stable.

1 Like

De mon côté, je suis en testing 3.7.0.6 sur une Raspberry Pi 3 (qui n’est pas en prod’) et pour l’heure ça fonctionne avec phpMyAdmin, Rainloop et Custom Webapp (avec un CMS dedans sans Base De Données pour l’école en cette période).
Raspberry Pi qui sert à CI package check en temps normal.

ppr

1 Like

Sur le panel admin, dans la catégorie Utilisateurs, j’ai un bouton sans texte (“groups_and_permissions_manage”) qui redirige vers l’accueil de l’admin.

Screenshot

Le même bouton est sur le descriptif d’une application, il redirige également vers l’accueil de l’admin. Avec également un problème de string sur ce même écran, de plus les permissions pour SOGo étaient définies à “Tout le monde” en 3.6 et maintenant, d’après l’écran, en “nobody”. Est-ce normal ?

Screenshot

EDIT : après un clear de cache du navigateur et un redémarrage du serveur, tous les problèmes cités au dessus sont résolus

Hello,

J’ai migré mon instance sur Yunohost 3.7. En fait je constate qu’il y a encore un problème (de mon point de vue, peut être que oublié une subtilité).

Ce qu’il se passe actuellement c’est que pour les app anciennement pour certaines app on mettais la règle suivante:
unprotected_uris /
Ceci signifiait que tous le monde à accès n’importe quel url de l’application, cependant uniquement théoriquement uniquement les utilisateurs autorisé à accéder à l’application devait pouvoir s’authentifier.

Par exemple, j’utilise ce type d’accès pour gitea, wordpress, ou seafile car je souhaite que n’importe qui puisse visiter l’application (en cas de partage à une personne sans compte Yunohost), cependant le but n’est pas forcément que tous les utilisateurs yunohost puissent s’authentifier dans l’application.

Avec le nouveau système de permission, cela à été migré dans ce cas là, que obligatoirement le group all_users est dans la permission seafile.main, wordpress.main ou gitea.main. Par contre pour moi là c’est problématique car on ne souhaite pas forcément que tous les utilisateurs puissent s’authentifier dans l’application et aient un bouton pour l’application dans la page /yunohost/sso.

Voilà je sais pas si mon explication est claire, ca reste un cas particulier mais à mon avis ca impacte pas mal d’application et dans mon cas j’ai quand même 25% de mes application impactée par ce problème.

Petite autre question : c’est marqué dans la doc que skipped_uris est déprécié. Quel est son remplacement ? Car pour moi l’utilisation du groupe visitors remplace uniquement unprotected_uris.

Mais du coup, avant ça, ces 3 apps ne s’affichaient pas dans le sso …?

Ou tu peux dire que pour toi, ça n’a de sens d’afficher les tuiles que si l’utilisateur peut effectivement s’authentifier sur wordpress etc ? (Mais du coup il faudrait un autre dashboard qui liste les apps publiques, comme discuté de temps en temps …)

Lorsque j’ai écrit ça, j’ai considéré que skipped_uris est grosso-modo juste un autre nom de unprotected_uris car plein d’apps, à cause de copier-coller, semble utiliser skipped_uris pour donner l’accès public à la place de unprotected_uris. Même si je sais que certaines apps ont vraiment besoin du skipped comme workaround le temps d’implémenter/merger le noauth (c.f. bitwarden, peertube etc.). Perso je n’ai pas en tête d’autres cas d’usage “legitime” de skipped

Mais du coup, avant ça, ces 3 apps ne s’affichaient pas dans le sso …?

Non, normalement elles étaient pas affichée vu que les tuiles étaient basée sur les settings, et que du coup pour wordpress il y avait uniquement 1 user qui avais accès.

C’est vrais que le skipped n’est peut être plus nécessaire quand le noauth sera implémenté. Perso je l’utilise généralement quand c’est des uris pour des API dont c’est uniquement des application et pas des navigateurs qui y accèdent.

Donc si je comprends bien, tu avais quelque chose comme :

unprotected_uris: /
allowed_users: johndoe

Du coup tout le monde avait accès, mais il n’y avait que johndoe qui avait une tuile ?

Perso ça me parait compliqué de reproduire ça avec le nouveau système car unprotected_uris: / est littéralement traduit en “tout le monde a accès” (et donc implicitement, tous les utilisateurs enregistrés sont “allowed”)

En fait j’ai du mal à voir quel est l’intention derrière vouloir avoir ce comportement, car pour moi si une personne a accès, alors elle doit voir la tuile … Et si elle ne voit pas la tuile, elle n’a pas accès…

Enfin note que si dans tout ça il s’agit de l’authentification sur l’app et/ou de l’accès a la partie admin de l’app, ça peut être géré justement via le nouveau système en ajoutant une permission wordpress.admin par exemple, qui correspondrait à domain.tld/blog/wp-admin. (Et dans ce cas, seul les users autorisés auraient une tuile “Wordpress admin”, et les autres seraient renvoyés vers le SSO si ils essayent de se logger)

Voici un exemple, j’ai l’application seafile (ou nextcloud). Pour des raison technique (accès API, partage de fichier), on doit mettre unprotected_uris: /, mais c’est pas pour autant qu’on souhaite que tous les utilisateurs yunohost puissent avoir un compte seafile et déposer des fichier. Et actuellement pour moi ce cas n’est pas supporté. A mon avis ce cas était peut être supporté avant que le groupe visitor aie été intégré.

Ce que je propose ca serait d’autoriser le fait que le groupe visitor soie autorisé sans pour autant que le group all_users soie autorisé. Pour ces applications on aurais donc des accès comme ceci:

seafile.main:
  - userA
  - userB
  - visitors

Signifiant que userA, userB à accès à l’application seafile et à sa tuile affichée dans le SSO, par contre le userC luis ne pourra pas s’authentifier et n’aura pas de tuile dans le SSO. Par contre si userA luis partage un fichier avec un liens publique là il peux accéder comme un visiteur.

I’m in favor of what @Josue saying, and actually I didn’t notice that. Which is going to be a problem for me as well.

In a different use case, I have multiple apps that are public, but I’m the only one to have it on my ynh portal.
Because, for many of my users, I don’t want them to have those apps on their portal. They have no reason to see them there.
Still, when I share a link, for the purpose of an API, or just because the app is for my own usage but public, those app are publicly accessible.

Do the listed issues/points from the test-installations above prevent version 3.7 to go to stable / release or is it on hold back due to other reason?

Enjoy :partying_face:

5 Likes