Have a “private” category that only has create/reply/see access for members of a specific group. No other permissions.
Enable “anonymous email in” for that specific via a unique working alias to the incoming POP account.
Have a non-staff user that is not a member of the group send an email report in to the category email address from the email address associated with their account.
Send in an email from an account not associated with any known Discourse account.
Expected Behavior:
Both #3 and #4 result in new topics in the private category, and the group can begin discussion.
Actual Behavior:
The email in #4 works but email in #3 is rejected with the can_create? failed error.
When we receive an email, we first try to associate it to a user, and then we check for permissions. Since the user isn’t part of the group, they can’t post.
The email_in_allow_strangers field on the category only works for staged users.
Can confirm #3 still not working. Is the best workaround right now to have emails directed at a group rather than a category? Not my preferred arrangement but I can switch until a patch comes out.
This scenario seems to be replaced these days with the group functionality as a type of workaround, although I could see some use cases that it might still be just as valuable for categories/topics/discussions.
Like you say, this is just a (bad) workaround. IMO this should be controllable on a per-category level. Clearly a bug that this works only for anonymous but not for known users.
I just ran into this issue while trying to set up a category for our organizations info list. This category only allows a certain group to access it, but we selected the option to allow emails from anonymous users. Email addresses that are not associated with any of our discourse users can send a message that will show up in the category, but registered users that are not in the group get rejected due to “Insufficient Trust Level”. I think I understand the technical reason why it works this way (only works for staged users) but is there a reason why this would be the desired or expected behavior? It seems to me if we are choosing to allow anonymous users we probably want to allow all registered users as well.
Wir hatten letzte Woche ebenfalls dieses Problem auf unserer Seite. Bei uns sieht die Situation wie folgt aus:
Obwohl die meisten unserer Kategorien nur für registrierte Benutzer gedacht sind, wollten wir eine Möglichkeit schaffen, dass Nicht-Mitglieder der Community per E-Mail Kontakt zu den Kernentwicklern aufnehmen können, um eine kurze Frage zu stellen, ein Anliegen vorzubringen usw.
Dazu haben wir eine Kategorie eingerichtet, die E-Mails von anonymen Nutzern über eine benutzerdefinierte Adresse entgegennimmt (z. B. ourproject+contact@discoursemail.com). Die Berechtigungen für diese Kategorie haben wir so eingestellt, dass sie nur für Kernmitglieder des Projekts lesbar sind, um zu vermeiden, dass zu viele Mails oder unnötiger Lärm für die gesamte Community entstehen (was bedeutete, dass Themen auch von Kernmitgliedern erstellt und beantwortet werden können müssen, da es keine Möglichkeit gibt, den Lesezugriff einzuschränken, ohne gleichzeitig den Zugriffsrecht zum Erstellen und Beantworten zu begrenzen).
Danach haben wir jedoch erfahren, dass anonyme Nutzer, die später ein offizielles Konto erstellen, keine E-Mails mehr an die Kontaktadresse senden können. Dies erscheint kontraintuitiv, da sie nun offizielier und registriert sind als zuvor, aber strikt weniger tun können als vorher.
Das hat mich vor dem Finden dieses Themas sehr verwirrt und scheint immer noch eine unglückliche Situation zu sein.
Dieses Problem besteht weiterhin in Version 2.7.8. Es ist verwirrend, dass eine E-Mail an die mit einer Kategorie verknüpfte E-Mail-Adresse akzeptiert wird, wenn der Absender kein registriertes Konto im Forum hat, und abgelehnt wird, wenn er eines hat.
Ich glaube, dass der folgende Patch (gegen den aktuellen main-Branch) dieses Problem lösen könnte, indem er Validierungen überspringt, wenn email_in_allow_strangers für die Kategorie gesetzt ist, genau wie dies bei gestaffelten Benutzern der Fall ist. Klingt das sinnvoll?
diff --git a/lib/email/receiver.rb b/lib/email/receiver.rb
index 7c76c44d61..dd3bc3cfb0 100644
--- a/lib/email/receiver.rb
+++ b/lib/email/receiver.rb
@@ -762,7 +762,7 @@ module Email
elided: elided,
title: subject,
category: destination.id,
- skip_validations: user.staged?)
+ skip_validations: (user.staged? || destination.email_in_allow_strangers))
elsif destination.is_a?(PostReplyKey)
# Wir staffeln keine neuen Benutzer für E-Mails an Antwortadressen, beenden, wenn der Benutzer nil ist
Es funktioniert nicht, weil Validierungen sich auf den Inhalt des Beitrags beziehen, nicht auf Berechtigungen, einen Beitrag zu erstellen oder nicht…
Ich habe den untenstehenden Patch getestet, und er funktioniert. Es ist ein Hack – probieren Sie das bitte nicht zu Hause aus Sein Verdienst besteht darin, grob zu identifizieren, wo Änderungen vorgenommen werden sollten. Die Herausforderung besteht darin, herauszufinden, wie man das auf ordentliche Weise umsetzt. Jeder Rat wäre höchst willkommen
diff --git a/app/jobs/regular/notify_mailing_list_subscribers.rb b/app/jobs/regular/notify_mailing_list_subscribers.rb
index c535296105..1d3bf79637 100644
--- a/app/jobs/regular/notify_mailing_list_subscribers.rb
+++ b/app/jobs/regular/notify_mailing_list_subscribers.rb
@@ -74,7 +74,7 @@ module Jobs
DiscourseEvent.trigger(:notify_mailing_list_subscribers, users, post)
users.find_each do |user|
- if Guardian.new(user).can_see?(post)
+ if Guardian.new(user).can_see?(post) && Guardian.new(user).can_see_category_staged?(post.topic.category)
if EmailLog.reached_max_emails?(user)
skip(user.email, user.id, post.id,
SkippedEmailLog.reason_types[:exceeded_emails_limit]
diff --git a/app/models/category.rb b/app/models/category.rb
index 630a74c425..6c253650c6 100644
--- a/app/models/category.rb
+++ b/app/models/category.rb
@@ -201,7 +201,7 @@ class Category < ActiveRecord::Base
end
else
permissions = permission_types.map { |p| CategoryGroup.permission_types[p] }
- where("(:staged AND LENGTH(COALESCE(email_in, '')) > 0 AND email_in_allow_strangers)
+ where("(LENGTH(COALESCE(email_in, '')) > 0 AND email_in_allow_strangers)
OR categories.id NOT IN (SELECT category_id FROM category_groups)
OR categories.id IN (
SELECT category_id
@@ -209,7 +209,6 @@ class Category < ActiveRecord::Base
WHERE permission_type IN (:permissions)
AND (group_id = :everyone OR group_id IN (SELECT group_id FROM group_users WHERE user_id = :user_id))
)",
- staged: guardian.is_staged?,
permissions: permissions,
user_id: guardian.user.id,
everyone: Group[:everyone].id)
diff --git a/lib/guardian/category_guardian.rb b/lib/guardian/category_guardian.rb
index 94a48466d6..2a4ba8015c 100644
--- a/lib/guardian/category_guardian.rb
+++ b/lib/guardian/category_guardian.rb
@@ -64,6 +64,14 @@ module CategoryGuardian
end
def can_see_category?(category)
+ return false unless category
+ return true if is_admin?
+ return true if !category.read_restricted
+ return true if category.email_in.present? && category.email_in_allow_strangers
+ secure_category_ids.include?(category.id)
+ end
+
+ def can_see_category_staged?(category)
return false unless category
return true if is_admin?
return true if !category.read_restricted
Ich denke, das Verhalten ist hier absichtlich. Eine Korrektur wird ziemlich umfassend ausfallen müssen.
Das Problem beim Zulassen, dass Personen ein Thema mit einem bestehenden Konto verknüpfen, besteht darin, dass jeder die E-Mail-Adresse eines anderen gefälscht verwenden kann.
Ich denke, der langfristige Weg zur Lösung dieses Problems ist folgender:
sam@somewhere.com hat ein Konto bei Discourse.
sam@somewhere.com sendet eine E-Mail an eine Kategorie mit dem Betreff „anonyme E-Mail".
Discourse sendet eine E-Mail an sam@somewhere.com: „Es sieht so aus, als hättest du folgenden Beitrag verfasst: INHALT DES BEITRAGS, unter der Discourse-URL. War das wirklich du?"
Klicke auf „Ja".
Das Thema wird erstellt.
Ohne diesen Schutz wäre diese Funktion anfällig für Identitätsdiebstahl, was ein sehr hohes Risiko darstellt.
Gibt es dieses Problem nicht bereits unabhängig von dem Parameter E-Mails von anonymen Benutzern ohne Konten akzeptieren?
Ich teile diese Ansicht: Wenn eine E-Mail mit einer Kategorie verknüpft ist und das Feld E-Mails von anonymen Benutzern ohne Konten akzeptieren aktiviert ist, sollte eine eingehende E-Mail
die mit einem Discourse-Konto verknüpft ist
die gemäß den Sicherheits-Parametern der Kategorie keine Leseberechtigung für die Nachrichten hat
Schützt die heute weitaus häufigere Verwendung von SPF/DKIM/DMARC im Vergleich zu 2016 nicht in ausreichendem Maße dagegen?
Jeder gute E-Mail-Anbieter (für den Benutzer) erlaubt anderen Benutzern nicht, von Adressen zu senden, die ihnen nicht gehören, und jeder gute E-Mail-Anbieter oder empfangende Dienst (für die Discourse-Instanz) sollte E-Mails ablehnen, die die Herkunftsvalidierung nicht bestehen.
Es wird Anbieter geben, die die Von-Adresse nicht validieren und/oder keine SPF/etc.-Einträge einrichten, aber wenn ein Benutzer sich entscheidet, einen E-Mail-Anbieter zu nutzen, der nichts gegen Identitätsdiebstahl unternimmt, erscheint es vernünftig, dass er imitiert werden kann.
Ich habe mich nicht besonders tief damit beschäftigt, aber es sieht so aus, als ob Email::AuthenticationResults bereits eine Ursprungsvalidierung durchführt. Vielleicht könnte kurzfristig das Ergebnis verfügbar gemacht werden (falls es das nicht schon ist), sodass diese E-Mails mit einem positiven Ergebnis akzeptiert werden können.
Bei Ihrer langfristigen Lösung könnte die Verifizierung „waren Sie es wirklich?“ auch übersprungen werden, wenn das Ergebnis positiv ist.
Sein Verdienst besteht darin, grob zu identifizieren, wo Änderungen vorgenommen werden sollten. Die Herausforderung besteht darin, herauszufinden, wie man das auf ordentliche Weise umsetzt. Jeder Rat wäre höchst willkommen 