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.
Nous avons rencontré ce problème sur notre site la semaine dernière également. Pour nous, la situation est la suivante :
Bien que la plupart de nos catégories soient destinées uniquement aux utilisateurs inscrits, nous souhaitions permettre aux non-membres de la communauté de contacter les développeurs principaux par e-mail pour poser une question rapide, soulever une préoccupation, etc.
Pour cela, nous avons configuré une catégorie pour accepter les e-mails provenant d’utilisateurs anonymes via une adresse personnalisée (par exemple, ourproject+contact@discoursemail.com). Nous avons restreint les permissions de cette catégorie afin qu’elle soit lisible uniquement par les membres principaux du projet, afin d’éviter de générer trop de courriels ou de bruit pour l’ensemble de la communauté (ce qui impliquait également de permettre aux membres principaux de créer et de répondre aux sujets, car il n’est pas possible de restreindre l’accès en lecture sans limiter également l’accès à la création et à la réponse).
Cependant, nous avons ensuite appris que si un utilisateur anonyme créait ensuite un compte officiel, il ne pouvait plus envoyer de courriels à l’adresse de contact. Cela semble contre-intuitif, car ils sont désormais plus officiels et inscrits qu’auparavant, mais peuvent strictement moins faire qu’avant.
Cela m’a causé une grande confusion avant que je ne tombe sur ce sujet, et cela semble toujours être une situation regrettable.
Ce problème persiste en version 2.7.8. Il est déroutant qu’un courriel envoyé à l’adresse associée à une catégorie soit accepté lorsque l’expéditeur ne possède pas de compte enregistré sur le forum, et soit rejeté s’il en a un.
Je pense que le correctif suivant (par rapport à la branche main actuelle) pourrait résoudre ce problème en sautant les validations lorsque email_in_allow_strangers est défini pour la catégorie, de la même manière que cela est fait pour les utilisateurs en cours de mise en scène. Cela vous semble-t-il logique ?
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)
# Nous ne mettons pas en scène les nouveaux utilisateurs pour les e-mails envoyés aux adresses de réponse, sortons si l'utilisateur est nil
Cela ne fonctionne pas car les validations concernent le contenu du message, et non les permissions pour créer ou non un message…
J’ai testé le correctif ci-dessous et il fonctionne. C’est un bricolage, ne tentez pas cela à la maison Son mérite est d’identifier grossièrement où les modifications doivent intervenir. Le défi consiste à déterminer comment procéder de manière appropriée. Tout conseil serait le bienvenu
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
Ce problème n’existe-t-il pas déjà, indépendamment du paramètre Accepter les e-mails des utilisateurs anonymes sans compte ?
Je partage ce point de vue : lorsqu’un e-mail est associé à une catégorie et que la case Accepter les e-mails des utilisateurs anonymes sans compte est cochée, un e-mail entrant
associé à un compte Discourse
qui n’est pas autorisé à lire les messages selon les paramètres Sécurité de la catégorie
L’utilisation de SPF/DKIM/DMARC, beaucoup plus répandue maintenant qu’en 2016, ne protège-t-elle pas suffisamment contre cela ?
Tout bon fournisseur de messagerie (pour l’utilisateur) n’autorisera pas d’autres utilisateurs à envoyer des courriels à partir d’adresses qui ne leur appartiennent pas, et tout bon fournisseur de messagerie ou service de réception (pour l’instance Discourse) devrait rejeter les courriels qui échouent à la validation d’origine.
Il existera des fournisseurs qui ne valident pas l’adresse de l’expéditeur et/ou qui ne configurent pas d’enregistrements SPF/etc., mais si un utilisateur choisit d’utiliser un fournisseur de messagerie qui ne fait rien pour se protéger contre l’usurpation d’identité, il semble raisonnable qu’il puisse être usurpé.
Je n’ai pas approfondi le sujet, mais il semble que Email::AuthenticationResults effectue déjà une certaine validation d’origine. Peut-être qu’à plus court terme, le verdict pourrait être rendu disponible (s’il ne l’est pas déjà) afin que ces e-mails puissent être acceptés avec un verdict de réussite.
Dans votre solution à long terme, la vérification « était-ce vraiment vous ? » pourrait également être ignorée en cas de verdict de réussite.
Son mérite est d’identifier grossièrement où les modifications doivent intervenir. Le défi consiste à déterminer comment procéder de manière appropriée. Tout conseil serait le bienvenu 