What type of hardware are you using: Other ARM board What YunoHost version are you running: 12.0.17 What app is this about: Stirling-PDF
Describe your issue
Please excuse my beginner question, I’m quite new to self-hosting.
I like Stirling PDF app but I would like not everyone to be able to connect to it. I tried to change the user group to all_users instead of visitors, but nothing changed. For now, if you go to the URL of the Stirling app running on my server, you should have access to it, without any credential request. This is not what I would like. How to limit the access to Stirling PDF app?
Dans la page Comptes > Groupes et autorisations, lorsque tu supprimes la permission “stirling PDF” au groupe “visiteurs”, ceux-ci réussissent malgré tout à atteindre l’application au lieu d’être dirigés vers la page de sso ?
As-tu supprimé les cookies ou testé en connexion privée ou encore sur un autre navigateur pour voir si ce comportement persistait ?
Merci pour ta réponse!
Oui c’est exactement ça. Stirling pdf ne fait plus partie des applis sous “Visitors” dans l’interface admin… et malgré tout je bypass l’interface de connexion yunohost si j’utilise l’URL - meme en utilisant la navigation privée ou changeant d’ordinateur (avec un vpn).
En explorant un peu, je me rends compte que ce problème arrive pour tous les sites définis avec un sous-domaine, ici stirling.domain.tld. Stirling PDF (comme tandoor, immich etc) requiert la définition d’un sous-domaine dédié lors de l’install et non d’une “sous-page” (domain.tld/stirling), qui n’est pas possible pour ces apps. Tous les applis définis avec une “sous-page” sont correctement redirigée vers le SSO de yunohost. Une idée de ce qui pourrait causer le problème?
PS: meme si le problème se révèle être plus général que juste l’app Stirling PDF. Il se trouve que dans mon cas c’est assez spécific à Stirling, car les autres app nécessitant la déf d’un sous-domaine (immich, tandoor, etc) possèdent toutes, sauf stirling, un système de connexion dédié.
D’abord est-ce que tu te souviens avoir modifié manuellement des fichiers sur ton instance ?
Ensuite, vois ce que retourne yunohost tools regen-conf nginx --dry-run
Non je n’ai pas le souvenir d’avoir touché à quoi que soit pendant la config du server. Je n’ai utilisé que l’interface graphique.
La commande “yunohost tools regen-conf nginx --dry-run” ne renvoie rien… dois-je tester sans le dry-run?
Non, non, c’est simplement pour voir si un fichier de conf nginx a été modifié manuellement.
Avec sudo cat /etc/ssowat/conf.json regarde dans ce fichier si stirling-pdf.main a la valeur “false” pour la clé “public”
ou ‘public’ est en effet false.
Si la conf nginx peut causer des soucis, alors je me demande si le probleme vient de mon DNS? Je sais que c’est peu conventionel mais étant coincé derrière un CGNAT, j’ai du contourner mon problème en utilisant un tunnel Cloudflare. Se pourrait-il que se soit l’origine du problème? Je pensais que cette couche logiciel se situait au dessus de nginx et autres (pour mettre en place le tunnel je n’ai d’ailleurs pas eu besoin de toucher à aucun de paramètres du server).
Dsl pour la réponse tardive.
Oui meme problème lorsque je change de réseaux.
Si le problème vient de là, j’en suis navré; je ne pensais pas que Cloudflare tunnel pouvait contourner les restrictions de yunohost sur les accès aux apps. Je vais creuser. Merci de m’avoir aider en tout cas, ça m’a donné des outils et des pistes de recherche!