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.
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 ?
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 
5 Likes