PMs are accesible by admins if the admin has the link

I just found out that if someone sends a PM to other person. Let’s say from account joe to jane, and for some reason someone (logged in) finds out the right “topic ID” it can read the PM.

I know is kinda a edge-case and is rather difficult to find out, but automating some kind of scraper to cicle trough all the topics ID anyone could read all the PMs.

I found out because a user replied to the notification email, and I was able to click the link and read the PM in question.

I’m assuming you are a staff member on the forum? You should only be able to do this if you are staff. Staff should have the ability to audit PMs by default, and admins and those with access to the DB would have access to the raw messages anyway.

If you’re needing to provide a truly private system, there is the discourse-encrypt plugin which provides end-to-end encryption of messages.

9 « J'aime »

It’s not a necessity, just didn’t got a thought in that one.

I’ll test with a normal account and update this, just in case.

1 « J'aime »

This is only true for admins, not moderators, so I am editing your title which is incorrect. Moderators also only have access to PMs when they are flagged.

If this is a concern, demote yourself to moderator (by logging in under a different account to taste), or enable logging of PM visits by admins in your site settings.

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 »