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 „Gefällt mir“

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 „Gefällt mir“

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 „Gefällt mir“

Potenziell dumme Frage – wo genau ist diese Einstellung? Wir sind auf Stable (was theoretisch diesen Schalter haben sollte) und ich kann sie beim besten Willen nicht finden.

Bearbeiten: Unser anderer Administrator hat sie gefunden – es ist „log personal messages views“ im Tab „Users“. Ich würde argumentieren, dass dies eine Sache des Security-Tabs sein sollte, aber ich kann verstehen, warum es stattdessen dort wäre, wenn ich kurz darüber nachdenke.

2 „Gefällt mir“

Nachfrage – Ist es möglich, die Protokollierung zu aktivieren, wenn ein Administrator die Nachrichten eines Kontos eingesehen hat, auch wenn er eine Nachricht nicht geöffnet hat, um ihren Inhalt zu lesen?

Im Kontext unseres Forums wäre es Administratoren möglich, ihre Macht zu missbrauchen, indem sie lediglich die Details bestimmter PMs sehen, an denen ein Benutzer beteiligt ist – das Lesen der Inhalte ist nicht unbedingt schädlicher als das Wissen um den Namen und die Benutzer, die Zugriff haben, was derzeit trotz aktivierter Einstellung nicht protokolliert wird. Idealerweise möchten wir dies beheben und auch protokollieren, wann immer ein Administrator die Nachrichten eines Benutzers einsehen, an denen er beteiligt ist, anstatt nur, wenn er den Inhalt einer bestimmten Nachricht einsehen.

1 „Gefällt mir“

Der beste Weg, dies zu tun, ist mit Ende-zu-Ende-Verschlüsselung, die durch unser discourse-encrypt-Plugin ermöglicht wird.

Admins sind Administratoren des Forums und haben Zugriff auf alle Daten. Es gibt viele Möglichkeiten für Admins, Nachrichten einzusehen, ohne dass dies protokolliert wird:

  • Herunterladen eines Backups
  • Daten-Explorer
  • Nachahmung
  • Erstellen von API-Schlüsseln

Um Benutzer vollständig zu schützen, ist die beste Lösung die Verwendung von verschlüsselten Nachrichten. Wenn Sie Ihren Admins nicht vertrauen, sollten sie keine Admins sein.

5 „Gefällt mir“

Mein Verständnis ist, dass die meisten dieser Dinge protokollierbar sind, was alles ist, was wir wirklich brauchen – ehrlich gesagt bin ich mir nicht sicher, ob ich mir selbst vertraue, nicht versehentlich die Nachrichten-Seite eines Benutzers anzusehen und dann einfach weiterzumachen, als wäre nichts geschehen, was in unserem Fall schädlich sein könnte (insbesondere erwarten wir nicht, dass es ein Sicherheitsrisiko darstellt, sondern ein Integritätsrisiko – d. h. langfristige Schäden entstehen nicht, solange der Benutzer, der Zugang zu diesem Wissen erlangt hat, offen damit umgeht und sich von relevanten Themen zurückzieht).\n\nEs würde sicherlich viel einfacher machen, sicherzustellen, dass niemand dies versehentlich oder absichtlich tut, ohne es dann zu melden, wenn es zusammen mit allen anderen Möglichkeiten, auf dieselben Daten zuzugreifen, protokolliert würde.\n\nWenn die von Ihnen aufgeführten Dinge nicht protokollierbar sind, sollten sie es wirklich sein, aber selbst dann würde es nur gegen einen böswilligen Administrator helfen und nicht gegen einen leichtsinnigen.

1 „Gefällt mir“

Sie können Nachrichtentitel in den Nachrichtenlisten anderer Benutzer mit Ihrem Website-Theme ausblenden/verschleiern.

Wenn es mit Absicht geschieht, ist das eine andere Sache.

Andere Orte, an denen Sie diese Audit-Informationen erhalten könnten: die Webserver-Protokolle.

Ich bin sicher, dass ein Plugin zum Protokollieren dieser Informationen nicht schwierig wäre, aber ich bin mir nicht sicher, ob es auf unserer internen Roadmap stehen sollte.

2 „Gefällt mir“

Wie wäre es möglich, dies zu tun, ohne auch die eigenen Nachrichtenlisten zu verdecken? Soweit ich weiß, gibt es keinen Slug mit dem Benutzernamen des Kontos, das Sie anzeigen, den Sie verwenden könnten, um nur Nachrichten-Seiten, die nicht Ihre eigenen sind, mit CSS zu beeinflussen.

1 „Gefällt mir“

Sie könnten einen Selektor für den Titel auf dieser Seite verwenden – „Nachrichten“ ist Ihre, während „Benutzername — Nachrichten“ die eines anderen ist.

2 „Gefällt mir“

Mein Hauptproblem ist, dass mein Skript die Daten abzurufen scheint, bevor sie aktualisiert werden – d. h., ich kann die Metadaten bei einer Seitenänderung lesen, aber sie werden aktualisiert, bevor die Seitendaten aktualisiert werden.

<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>

Im Grunde wird mein --currUsername aktualisiert, dann wird das Meta-Tag mit der neuen URL aktualisiert, sodass mein --currUsername immer eine Seite hinter dem zurückbleibt, was ich mir eigentlich ansehe. Dies geschieht unabhängig davon, ob die Zeile „window.onload“ vorhanden ist oder nicht.

Haben Sie eine Idee, was ich hier falsch mache?

Das Endziel ist im Grunde, der Body-Klasse basierend auf der betrachteten Seite eine Klasse hinzuzufügen und dann entsprechend zu stylen – dies sollte es ermöglichen, beispielsweise das Titel-Feld anstelle des og:url-Feldes zu lesen und dann eine „myMessages“-Klasse auf den Body zu legen, um den gewünschten Effekt in diesem Fall zu erzielen. Theoretisch.

1 „Gefällt mir“

Dies ist unglaublich holprig, aber das Folgende scheint zu funktionieren, indem die JavaScript-Funktion gezwungen wird, eine zwanzigste Sekunde zu warten:


    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));
    }

Ich werde sehen, ob ich das wie beabsichtigt zum Laufen bringen kann.

2 „Gefällt mir“