New signup with old email including + doesnt work in rest API

Support
1

It seems in a recent update, new signup with same email including a + to represent a new email isnt allowed. my system is highly dependent on it. how to enable it again?

for example if I have already signup with email@gmail.com, I cant signup with email+1@gmail.com

btw I am testing this with rest api

image
image1292Ă—1638 208 KB

also, I dont have this option checked:

image
image1362Ă—239 15.5 KB

2

I believe that’s the normalize emails admin setting: :+1:

image
image1383Ă—393 10.8 KB

Edit: I did not see that edit before I posted. :slight_smile:

1 Like
3

yes it is already disabled for me

1 Like
4

I can’t duplicate this on try.discourse.org.

Can you sign up from the normal UI with this email?

Also, can you double check the +1 email wasn’t already used for a signup?

1 Like
5

yes normal UI is ok. rest api is not ok.

6

I did exactly the same and could not duplicate the problem on the latest code running live - it behaved as expected with the normalize emails setting disabled:

image
image914Ă—994 66.1 KB

Can you show the output of these from the rails console:

[1] pry(main)> SiteSetting.normalize_emails

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

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

Also, what version of Discourse are you on?

I might also double check you’re hitting your production site and not your test one (or vice versa).

2 Likes
7

I updated right now

here it is

image
image1920Ă—1319 142 KB

8

What do these translate to?

image

(and can you copy/paste them here)

I should have asked this first :man_facepalming:

9

image
image1316Ă—490 10.8 KB

“Primary email مجاز نیست.”

it is a translation for user.email.blocked

10

hmmm

it seems the normalized email is blocked. :thinking:

I mean if email@gmail.com is blocked, then email+1@gmail.com is blocked too. it is wierd to me when I have not normalized email option selected.

11

That’s why I should have asked first instead of assuming it was “already taken” :rofl:

What are your overridden settings in the email and user categories?

Have you blocked that email address, or, say, the Gmail domain?

1 Like
12

I didnt underestand this. where should I check?

yes I can see the normalized email is blocked.

13

In this case we almost definitely block subaddresses of blocked addresses regardless of the setting as an anti-griefing measure since the normalisation option is not the default.

“Only show overridden” in settings. But now I suspect we don’t need to worry about that.

2 Likes
14

Back at my desk I took a look at the actual code that does this rejection:

Right at the top we’re checking the canonical email against the blocklist:

  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

And even if that didn’t catch it, it would be caught by the Levenshtein distance check here:

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

as the default for SiteSetting.levenshtein_distance_spammer_emails is 2.

2 Likes
15

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