Les MP sont accessibles par les administrateurs si l'administrateur possède le lien

Je viens de découvrir que si quelqu’un envoie un MP à une autre personne. Disons, depuis le compte joe vers jane, et pour une raison quelconque, une personne (connectée) trouve le bon « ID de sujet », elle peut lire le MP.

Je sais que c’est un peu un cas limite et qu’il est plutôt difficile de le découvrir, mais automatiser un type de scraper pour parcourir tous les IDs de sujets permettrait à n’importe qui de lire tous les MP.

Je l’ai découvert parce qu’un utilisateur a répondu à l’email de notification, et j’ai pu cliquer sur le lien pour lire le MP en question.

Je suppose que vous êtes membre du personnel du forum ? Vous ne devriez pouvoir le faire que si vous êtes membre du personnel. Le personnel devrait avoir la possibilité d’auditer les messages privés par défaut, et les administrateurs ainsi que ceux ayant accès à la base de données auraient accès aux messages bruts de toute façon.

Si vous avez besoin de fournir un système véritablement privé, il existe le plugin discourse-encrypt qui assure un chiffrement de bout en bout des messages.

9 « J'aime »

Ce n’est pas une nécessité, j’ai juste oublié d’y penser.

Je vais tester avec un compte normal et mettre à jour ceci, au cas où.

1 « J'aime »

Cela ne s’applique qu’aux administrateurs, pas aux modérateurs, c’est pourquoi je modifie votre titre qui est incorrect. Les modérateurs n’ont également accès aux messages privés que lorsqu’ils sont signalés.

Si cela vous préoccupe, rétrogradez-vous au rang de modérateur (en vous connectant avec un autre compte pour tester), ou activez la journalisation des visites de messages privés par les administrateurs dans les paramètres de votre site.

5 « J'aime »

Question potentiellement stupide - où se trouve exactement ce paramètre ? Nous sommes sur la version stable (qui devrait vraiment avoir ce bouton, en théorie) et je ne le trouve pas.

Edit : Notre autre administrateur l’a trouvé - il s’agit de « log personal messages views » dans l’onglet « Users ». Je dirais que cela devrait être dans l’onglet Sécurité, mais je peux comprendre pourquoi il serait là si j’y réfléchissais une minute.

2 « J'aime »

Question de suivi - est-il possible d’activer la journalisation lorsqu’un administrateur a consulté les messages d’un compte, même s’il n’a pas ouvert de message pour en lire le contenu ?

Dans le contexte de notre forum, il serait possible pour les administrateurs d’abuser de leur pouvoir en se contentant de voir les détails de certains messages privés dont un utilisateur peut faire partie - lire le contenu n’est pas nécessairement plus dommageable que de connaître le nom et quels utilisateurs y ont accès, ce qui n’est actuellement pas enregistré malgré l’activation de ce paramètre. Idéalement, nous aimerions corriger cela, et également enregistrer chaque fois qu’un administrateur consulte les messages dont un utilisateur fait partie plutôt que seulement lorsqu’il consulte le contenu d’un message spécifique.

1 « J'aime »

La meilleure façon de procéder est le chiffrement de bout en bout, rendu possible par notre plugin discourse-encrypt.

Les administrateurs sont les administrateurs du forum et ont accès à toutes les données. Il existe de nombreuses façons pour les administrateurs de visualiser le contenu des messages sans qu’il soit enregistré :

  • télécharger une sauvegarde
  • explorateur de données
  • usurpation d’identité
  • création de clés API

Pour protéger pleinement les utilisateurs, la meilleure solution est d’utiliser la messagerie chiffrée. Si vous n’avez pas confiance en vos administrateurs, ils ne devraient pas être administrateurs.

5 « J'aime »

Ma compréhension est que la plupart de ces choses sont journalisables, ce qui est tout ce dont nous avons vraiment besoin - pour être honnête, je ne suis pas sûr de me faire confiance pour ne pas finir par regarder la page des messages d’un utilisateur par accident et passer ensuite comme si de rien n’était, ce qui dans notre cas pourrait être préjudiciable (en particulier, nous ne nous attendons pas à ce que ce soit un risque de sécurité, mais un risque d’intégrité - c’est-à-dire que des dommages à long terme ne sont pas causés tant que l’utilisateur qui a obtenu l’accès à ces informations est ouvert à ce sujet et se récuse des sujets pertinents).\n\nCela faciliterait certainement grandement de s’assurer que personne ne le fait par accident ou exprès sans ensuite le signaler, alors que toutes les autres façons d’accéder aux mêmes données le permettent.\n\nSi les choses que vous avez énumérées ne sont pas journalisables, elles devraient l’être, mais même ainsi, cela n’aiderait qu’un administrateur malveillant et non un administrateur légèrement négligent.

1 « J'aime »

Vous pouvez masquer/obscurcir les titres des messages dans les listes de messages des autres utilisateurs à l’aide de votre thème de site.

Si c’est intentionnel, c’est une autre affaire.

D’autres endroits où vous pourriez obtenir ces informations d’audit : les journaux du serveur Web.

Je suis sûr qu’un plugin pour enregistrer ces informations ne serait pas difficile, mais je ne suis pas sûr que cela devrait figurer sur notre feuille de route interne.

2 « J'aime »

Comment serait-il possible de le faire sans masquer également vos propres listes de messages ? Pour autant que je sache, il n’y a pas de “slug” avec le nom d’utilisateur du compte que vous consultez que vous pourriez utiliser pour affecter uniquement les pages de messages qui ne sont pas les vôtres avec CSS.

1 « J'aime »

Vous pourriez peut-être utiliser un sélecteur sur le titre de cette page : « Messages » est le vôtre, tandis que « Nom d’utilisateur — Messages » appartient à quelqu’un d’autre.

2 « J'aime »

Mon principal problème est que mon script semble récupérer les données avant qu’elles ne soient mises à jour - c’est-à-dire que je peux lire les métadonnées lors d’un changement de page, mais elles sont mises à jour avant que les données de la page ne soient mises à jour.

<script type="text/discourse-plugin" version="0.8">
    api.onPageChange(() => {
        window.onload = determineUser();
    });
    
    function determineUser() {
        var pageURL = document.querySelector("meta[property='og:url']").getAttribute("content");
        var userPage = pageURL.includes("https://www.fortressoflies.com/u/");
        document.documentElement.style.setProperty('--currUsername', pageURL);
        
        if(userPage)
        {
            document.documentElement.style.setProperty('--lastUsername', pageURL);
        }
    }
</script>

En gros, mon --currUsername est mis à jour, puis la balise meta est mise à jour avec la nouvelle URL, donc mon --currUsername a toujours une page de retard par rapport à ce que je regarde réellement. Cela se produit, que la ligne “window.onload” soit présente ou non.

Une idée de ce que je fais de travers ici ?

L’objectif final est à peu près d’ajouter une classe au corps en fonction de la page que vous regardez, puis de styliser en fonction de cela - cela devrait nous permettre de lire, par exemple, ce champ de titre au lieu du champ og:url, puis d’ajouter une classe “myMessages” au corps pour obtenir l’effet désiré dans ce cas. En théorie.

1 « J'aime »

C’est incroyablement bancal, mais ce qui suit semble fonctionner en forçant la fonction JavaScript à attendre un vingtième de seconde :


    api.onPageChange(() =>{
        window.onload = determineUser();
    });
    
    async function determineUser() {
        await sleep(50);
        var pageURL = document.querySelector("meta[property='og:url']").getAttribute("content");
        var userPage = pageURL.includes("https://www.fortressoflies.com/u/");
        document.documentElement.style.setProperty('--currUsername', pageURL);
        if(userPage)
        {
            document.documentElement.style.setProperty('--lastUsername', pageURL);
        }
    }
    
    function sleep(ms)
    {
        return new Promise(resolve => setTimeout(resolve, ms));
    }

Je vais voir si je peux faire en sorte que cela fonctionne comme prévu.

2 « J'aime »