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.
Nos enfrentamos a este problema en nuestro sitio la semana pasada también. Para nosotros, la situación es la siguiente:
Aunque la mayoría de nuestras categorías están destinadas solo para usuarios registrados, queríamos tener una forma de que un miembro no registrado de la comunidad pudiera ponerse en contacto con los desarrolladores principales por correo electrónico para hacer una pregunta rápida, plantear una preocupación, etc.
Lo hicimos configurando una categoría para aceptar correos de usuarios anónimos usando una dirección personalizada (por ejemplo, ourproject+contact@discoursemail.com). Establecimos que los permisos de la categoría fueran legibles solo por miembros principales del proyecto para evitar generar demasiado correo o ruido para la comunidad en general (lo que significó que también los temas pudieran ser creados y respondidos por miembros principales, ya que no hay forma de restringir el acceso de lectura sin limitar también el acceso para crear o responder).
Sin embargo, luego descubrimos que si el usuario anónimo creaba posteriormente una cuenta oficial, ya no podía enviar correos a la dirección de contacto. Esto parece contraintuitivo, ya que ahora son más oficiales y registrados que antes, pero pueden hacer estrictamente menos de lo que podían antes.
Esto me causó mucha confusión antes de encontrar este tema, y aún parece una situación desafortunada.
Este problema sigue existiendo en la versión 2.7.8. Es confuso que un correo enviado a la dirección de email asociada a una categoría sea aceptado cuando el remitente no tiene una cuenta registrada en el foro, y sea rechazado si la tiene.
Creo que el siguiente parche (contra la rama main actual) podría solucionar este problema al omitir las validaciones cuando email_in_allow_strangers está configurado para la categoría, de la misma manera en que se omite para usuarios en etapa de prueba. ¿Suena razonable?
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)
# No creamos usuarios nuevos en etapa de prueba para correos a direcciones de respuesta, salir si el usuario es nil
No funciona porque las validaciones se refieren al contenido de la publicación, no a los permisos para crear o no una publicación…
He probado que el siguiente parche funciona. Es un truco, no lo intentes en casa Su mérito es identificar aproximadamente dónde deben realizarse los cambios. El desafío es averiguar cómo hacerlo de la manera adecuada. Cualquier consejo será muy bienvenido
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
Creo que este comportamiento es intencional; una solución aquí tendrá que ser bastante exhaustiva.
El problema de permitir que las personas asocien un tema con una cuenta existente es que cualquiera puede falsificar el correo electrónico de cualquier otra persona.
Pienso que la forma de resolver esto a largo plazo es:
sam@somewhere.com tiene una cuenta en Discourse.
sam@somewhere.com envía un correo electrónico a una categoría con correo electrónico anónimo incluido.
Discourse envía un correo electrónico a sam@somewhere.com: “Parece que publicaste: CONTENIDO DEL MENSAJE, en la URL de Discourse. ¿Fue realmente tú?”.
Haz clic en Sí.
Se crea el tema.
Sin esta protección, esta función quedaría completamente abierta a la suplantación de identidad, lo cual es muy arriesgado.
¿No existe ya este problema, independientemente del parámetro Aceptar correos electrónicos de usuarios anónimos sin cuenta?
Comparto ese punto de vista: cuando un correo electrónico se asocia a una categoría y se marca la casilla Aceptar correos electrónicos de usuarios anónimos sin cuenta, un correo electrónico entrante
asociado a una cuenta de Discourse
al que no se le permite leer los mensajes según los parámetros de Seguridad de la categoría
¿El uso de SPF/DKIM/DMARC, que es mucho más prolífico ahora que en 2016, no protege contra esto en un grado suficientemente bueno?
Cualquier buen proveedor de correo electrónico (para el usuario) no permitirá que otros usuarios envíen desde direcciones que no les pertenecen y cualquier buen proveedor de correo electrónico o servicio de recepción (para la instancia de Discourse) debería rechazar correos electrónicos que fallen la validación de origen.
Existirán proveedores que no validen la dirección del remitente y/o no configuren registros SPF/etc., pero si un usuario elige usar un proveedor de correo electrónico que no hace nada para protegerse contra la suplantación de identidad, parece razonable que puedan ser suplantados.
No he profundizado mucho en ello, pero parece que Email::AuthenticationResults ya realiza alguna validación de origen. Quizás a corto (más corto) plazo, el veredicto podría estar disponible (si no lo está ya) para que estos correos electrónicos puedan ser aceptados con un veredicto de aprobación.
En su solución a largo plazo, la verificación “¿fuiste realmente tú?” también podría omitirse en caso de un veredicto de aprobación.
Su mérito es identificar aproximadamente dónde deben realizarse los cambios. El desafío es averiguar cómo hacerlo de la manera adecuada. Cualquier consejo será muy bienvenido 