Nouvelle inscription avec ancien email incluant + ne fonctionne pas dans l'API REST

Il semble que lors d’une mise à jour récente, la nouvelle inscription avec le même e-mail incluant un + pour représenter un nouvel e-mail ne soit pas autorisée. mon système en dépend fortement. comment le réactiver ?

par exemple, si je me suis déjà inscrit avec email@gmail.com, je ne peux pas m’inscrire avec email+1@gmail.com

au fait, je teste cela avec l’API REST

de plus, je n’ai pas cette option cochée :

Je pense qu’il s’agit du paramètre d’administration normalize emails : :+1:

Edit : Je n’avais pas vu cette modification avant de publier. :slight_smile:

1 « J'aime »

oui, il est déjà désactivé pour moi

1 « J'aime »

Je n’arrive pas à reproduire cela sur try.discourse.org.

Pouvez-vous vous inscrire depuis l’interface utilisateur normale avec cet e-mail ?

Vérifiez également que l’e-mail +1 n’a pas déjà été utilisé pour une inscription.

1 « J'aime »

oui l’interface utilisateur normale est ok. l’API REST n’est pas ok.

J’ai fait exactement la même chose et je n’ai pas pu reproduire le problème sur le dernier code en production - il s’est comporté comme prévu avec le paramètre normaliser les e-mails désactivé :

Pouvez-vous montrer la sortie de ces commandes depuis la console Rails :

[1] pry(main)> SiteSetting.normalize_emails

[2] pry(main)> User.find_by_email('VOTREPSEUDO@gmail.com').username

[3] pry(main)> User.find_by_email('VOTREPSEUDO+1@gmail.com').username

Quelle version de Discourse utilisez-vous ?

Je vérifierais également que vous accédez à votre site de production et non à votre site de test (ou vice versa).

2 « J'aime »

J’ai mis à jour maintenant

Voici

Qu’est-ce que cela donne en traduction ?

(et pouvez-vous les copier/coller ici)

J’aurais dû demander ça d’abord :man_facepalming:

“L’e-mail principal n’est pas autorisé.”
c’est une traduction pour user.email.blocked

hmmm

il semble que l’e-mail normalisé soit bloqué. :thinking:

Je veux dire, si email@gmail.com est bloqué, alors email+1@gmail.com est également bloqué. C’est étrange pour moi quand l’option e-mail normalisé n’est pas sélectionnée.

C’est pourquoi j’aurais dû demander d’abord au lieu de supposer que c’était « déjà pris » :rofl:

Quels sont vos paramètres remplacés dans les catégories d’e-mails et d’utilisateurs ?

Avez-vous bloqué cette adresse e-mail, ou, disons, le domaine Gmail ?

1 « J'aime »

Je n’ai pas compris ça. Où dois-je vérifier ?

Oui, je peux voir que l’e-mail normalisé est bloqué.

Dans ce cas, nous bloquons presque certainement les sous-adresses des adresses bloquées, quel que soit le réglage, comme mesure anti-abus, étant donné que l’option de normalisation n’est pas la valeur par défaut.

« Afficher uniquement les remplacements » dans les paramètres. Mais maintenant, je soupçonne que nous n’avons pas à nous en soucier.

2 « J'aime »

De retour à mon bureau, j’ai examiné le code réel qui effectue ce rejet :

Tout en haut, nous vérifions l’adresse e-mail canonique par rapport à la liste de blocage :

  def self.canonical(email)
    name, domain = email.split("@", 2)
    name = name.gsub(/\+.*/, "")
    name = name.gsub(".", "") if %w[gmail.com googlemail.com].include?(domain.downcase)
    "#{name}@#{domain}".downcase
  end

Et même si cela ne l’avait pas intercepté, il aurait été intercepté par la vérification de la distance de Levenshtein ici :

[1] pry(main)> ScreenedEmail.levenshtein('fakezabanshenas@gmail.com', 'fakezabanshenas+1@gmail.com')
=> 2

car la valeur par défaut pour SiteSetting.levenshtein_distance_spammer_emails est 2.

2 « J'aime »

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.