You are viewing limited content. For full access, please sign in.

Question

Question

LFDS new user email validation on form

asked on October 9

Hi,

I was trying to add a new user in LFDS, and came across a problem where the email address validation is failing to accept the email address of the user; they have an address akin to:

abc@company.design - ie. in one of the new TLDs.  DESIGN is the top level domain here, but LFDS appears to not recognize validation for those correctly... 

What is the fix here?

 

Tnx

 

Kris

0 0

Answer

SELECTED ANSWER
replied on October 10

A workaround you can try is this:

  1. Create the user with all claims except email
  2. Execute the following SQL query after backing up your database (replacing <email> and <userSid> with the desired email value and the desired user's SID):
update additional_claims
set str_val = '<email>'
where sid = <userSid> and claim_id = 1

Note: any time you want to update the user's claims you will need to remove the email value to save changes and then you must re-run the query to re-add their email.

0 0

Replies

replied on October 10

Chase -

Thanks!  In the meantime, what should I do to bypass the issue to allow me to create the user within the system?  Ie. how do I create a user at this point whose address I cannot enter in LFDS?  I need to create this account, but the system will not allow me to do so - what is the workaround?

 

To add to any ticket that may be open regarding validation rules:

You should not rely on any lookup list to determine what is a valid TLD.  The only way to validate an address would be to:

  • Validate the format, ie. check the 'local part' to have letters, digits or the characters !#$%&'*+-/=~_`{}| or .   The address may be quoted to include a sequence of . characters, for instance, and may also be an internationalized format using characters encoded in UTF-8...  Then, check the 'domain part' to comply to hostname requirements, which would include characters and digits, and the hyphen.  Internationalization rules come into play there too...  Also, validate that the local and domain parts are separated by the @ symbol...
  • The local part may be no longer than 64 actual characters (UTF-8 can play havoc with a simple count)
  • Validate that the domain has an MX record in DNS, or if no MX record, that at least an A or AAAA record exists for the domain.

Of especial note is to consider that the following *IS* a valid (except for the use of the reserved domain example.com):

" "@example.com

This is another valid address:
संपर्क@डाटामेल.भारत

 

I've read of other situations here on answers where a question has come up with the validation rules for email addresses, and it is disheartening to see that broken validation rules have been implemented on a platform of this caliber...

 

 

1 0
SELECTED ANSWER
replied on October 10

A workaround you can try is this:

  1. Create the user with all claims except email
  2. Execute the following SQL query after backing up your database (replacing <email> and <userSid> with the desired email value and the desired user's SID):
update additional_claims
set str_val = '<email>'
where sid = <userSid> and claim_id = 1

Note: any time you want to update the user's claims you will need to remove the email value to save changes and then you must re-run the query to re-add their email.

0 0
replied on October 10

OK - that works, though I really did not want to have to modify things directly in the DB on a per-user basis.  Would much rather have been able to modify the validation rules, or disable validation entirely on the back-end process for LFDS.  It is nice to see some validation there, but since it is an administrative tool, the assumption would be that the user entering data would have a clue...

0 0
replied on October 10

Hi Kris,

I do see your issue and notice that our email address validation will fail for several valid TLDs. I have filed a bug for this problem.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.