Je souhaiterais ouvrir certains services à des utilisateurs non inscrits sur mon serveur Yunohost mais sans laisser un accès total à n’importe qui. L’idée est de donner accès à des services comme pairdrop, send ou chitchatter par exemple à des proches ou des membres de la famille.
Il Faudrait pouvoir mettre une page de login avec un couple login/password pour ne donner accès qu’aux personnes auxquelles je transmettrais ces identifiants.
J’avais bien pensé à faire un utilisateur dédié à ça et de mettre la page en privé mais dans ce cas je ne pense pas que les applications fonctionneront avec des utilisateurs externes. Or des services comme send ou PsiTransfer nécessitent que le destinataire puisse accéder aux fichiers transmis.
Y-a-t-il possibilité de le faire avec Yunohost?
J’avais testé il y a longtemps Jirafeau et je crois que cette application le permettait. Donc ça doit être possible.
Je ne sais pas encore exactement ce que je mettrai en accès, je n’ai pas complètement défini mon besoin.
Pour chitchatter par exemple la création d’un salon en accès privé ne peut être accessible qu’avec un utilisateur Yunohost.
Pour Pairdrop avec un salon public, je suppose que ce sera la même chose, non?
Oui, mais je pense principalement à ces 3 applications. La plupart des autres applications ne demandent pas d’échange comme celles-ci et la page peut être privée sans souci.
Ce sont des applications “service” que je souhaite mettre, et non des applications “stockage” tel que Nextcloud. Disons une application qui n’a pas besoin d’être nominative.
Donc partage de fichiers (send,pairdrop) , visio (galène ou chitchatter) sorti de celles-là, je n’ai pas vraiment d’idée de ce que je pourrais ajouter qui nécessite un accès externe en étant derrière une page privée.
Donc si c’est possible pour Pairdrop et Chitchatter, ça serait top et ça remplit mon cahier des charges
pour pairdrop, je ne vois pas de problème à le laisser en accès public
l’app nécessite un appairage sécurisé, donc y’a pas de risque à laisser public
et certainement pareil pour chitchatter
Je me posais surtout la question des conditions d’utilisation et de législation a laisser un service ouvert. Et également si ça pouvais augmenter la charge du serveur à laisser le service accessible à tous le monde. Passer la page en privé avec un login me libère de cette contrainte je pense, peut-être à tord d’ailleurs vu que je rend le service quand même accessible à quelques personnes.
Clairement si tu files un service de manière officieuse à ~dizaine de personne, ça semble complètement overthink de se dire qu’il faut faire des CGU ou que ça va augmenter la charge serveur, c’est pas 3 requêtes de bot de temps en temps qui vont surcharger ton serveur. Et pour les CGU oui, le fait de mettre un mot de passe ne change rien
Je viens d’essayer avec la version 3.4.23~ynh3 qui est supposée pouvoir partager un lien tout en téléversant derrrière le SSO. D’une part je suis obligé de m’identifier sur le SSO avec le lien de téléchargement, secundo je n’ai pas accès au fichier et je reçois le message “lien expiré”, et l’adresse url est remplacée par https://domain.tld/404. Pourtant l’upload se passe bien et la page est accessible pour l’envoi.
Si je mets les permissions en mode visiteur, tout fonctionne. Donc l’accès aux liens ne me semblent toujours pas disponible avec cette version si l’app est protégée par le SSO.
Pour info ce serveur est en reverse proxy avec l’application Redirect (un Yunohost derrière un Yunohost) au cas où ça interfère.
C’est parfait ça fonctionne et ça n’a pas l’air d’interférer avec le SSO.
Reste à voir ce que je peux en faire si je ne peux pas donner accès aux liens avec cette méthode, cf ma réponse à @OniriCorpe ci-dessus. A défaut je ferai un utilisateur dédié mais pour l’instant j’ai le même résultat que ce soit avec le SSO ou ce mode de protection.
@metyun oui bien sûr que ça interfère, les règles qui permettent aux liens de téléchargement de ne pas être bloqués par le SSO configurent le SSO d’une certaine manière
si derrière tu met un reverse proxy avec un autre SSO par dessus, ça va coincer, par design
parce que le SSO de cette ynh n’est pas configuré pour, et que ça ne peut pas être fait automatiquement
tu devrais gérer les permissions d’accès PAR ynh et non tout gérer sur celle qui fait reverse proxy (sur celle-ci tu devrais uniquement faire du reverse proxy neutre, sans SSO)
parce que les bénévoles de ynh prévoient un cas d’usage harmonisé et que ton cas d’usage est un impensé qui de toute façon ne peut pas être pris en charge
aussi j’ai testé cette fonctionnalité de fond en comble pendant des heures, elle est à priori fonctionnelle
Big thanks , mais bien sûr , tu m’ouvres les yeux! Je faisais fausse piste en regardant du côté de la conf Nginx alors qu’évidemment c’était le SSO du reverse proxy qui bloquait. J’ai copié la conf du SSO concernant send.api et send.download sur le frontal et ça fonctionne.
Je vois que dans send.main il y a l’url domain.tld/api/upload d’ajoutée. Je ne l’ai pas sur ma conf redirect.main et ça a l’air de fonctionner. Faut-il l’ajouter?
J’utilise Yunohost en frontal tout simplement parce que je n’ai jamais essayé autre chose et que l’appli redirect est géniale. Il est peut-être temps pour moi de tester une autre solution de reverse-proxy pour avoir une configuration plus simple mais je ne sais pas trop vers quoi me tourner.
Pour la solution sans user proposée par @Aleks , je n’ai pas réussi à donner l’accès sans authentification aux download avec auth_basic off , certainement parce que je ne sais pas l’implanter correctement dans la conf de Nginx.
Une dernière question : Quand on accède au lien de téléchargement, il y a un bouton “Essayer Send”. En cliquant sur celui-ci en mode Visiteur, on accède à la page d’upload au lieu d’arriver sur le SSO déconnecté ou sur une page d’erreur. Est-ce un bug ou est-ce que ça vient de mon installation exotique?
Je n’ai pas réussi à laisser le second yunohost gérer les permissions d’accès, je n’accède pas au SSO de celui-ci.
La seule configuration qui fonctionne pour moi est de mettre le second yunohost avec toutes les permissions pour les visiteurs et de laisser le yunohost frontal en accès restreint aux utilisateurs derrière le SSO et de copier à partir du serveur2 les règles nécessaires aux applications dans le fichier /etc/ssowat/conf.json du serveur1.
Si je fais l’inverse en donnant l’accès aux applications “redirect” aux visiteurs et que je mets un accès restreint grâce aux permissions aux utilisateurs sur le second yunohost, ça ne fonctionne plus. Théoriquement ça devrait être le SSO du serveur2 qui devrait s’afficher mais ce n’est pas le cas.
Ce n’est pas exactement ma demande de base mais ça répond à mon besoin.
Ce problème n’est pas dû à mon installation, je l’ai testé sur un autre serveur directement accessible sans être derrière un reverse-proxy et le bouton “Essayer Send” permet d’uploader en tant que visiteur.
Je faisais fausse piste en regardant du côté de la conf Nginx alors qu’évidemment c’était le SSO du reverse proxy qui bloquait. J’ai copié la conf du SSO concernant send.api et send.download sur le frontal et ça fonctionne.