Fix Unicode Phone Number Validation in Mideye

Phone number validation failures prevent OTP delivery and are one of the most common issues encountered by administrators. Problems are usually caused by invisible Unicode characters, incorrect formats, or LDAP attribute mapping issues.

Overview

Mideye Server validates phone numbers before sending OTP messages. A valid phone number must:

• Start with + followed by the country code
• Contain only digits after the +
• Be 8–16 characters long (including +)
• Contain no spaces, dashes, or other formatting

Examples:

Format	Valid?	Notes
+46701234567	✅	Correct
+1-555-123-4567	❌	Contains dashes
+46 70 123 45 67	❌	Contains spaces
0701234567	❌	Missing country code
46701234567	❌	Missing +

---

Common Issues

1. Hidden Characters from Copy-Paste

Problem: A phone number that looks correct is rejected due to invisible Unicode characters introduced during copy-paste.

Symptoms:

• Phone number appears correct on screen
• Validation fails with no obvious reason
• The same number typed manually works fine

Root Cause: Copy-pasting from web pages, emails, Word documents, or spreadsheets can silently insert invisible characters:

Character	Unicode	Name	Common Source
(invisible)	U+200B	Zero Width Space	Web pages
(invisible)	U+200C	Zero Width Non-Joiner	Word processors
(invisible)	U+200D	Zero Width Joiner	Rich text editors
(invisible)	U+FEFF	Byte Order Mark (BOM)	Text files, Excel
(invisible)	U+00A0	Non-Breaking Space	HTML content
(invisible)	U+200E	Left-to-Right Mark	Bidirectional text
(invisible)	U+200F	Right-to-Left Mark	Bidirectional text
(invisible)	U+2060	Word Joiner	Document editors

Diagnostic Steps:

1. In the web interface: Navigate to the user in User Management and view the phone number field

2. Check for hidden characters:

   • Select the phone number, delete it entirely
   • Type the number manually (do not paste)
   • Save and test again

3. Identify hidden characters in the database:

   -- Check for non-printable characters in phone numbers
   SELECT username, phone_number, LENGTH(phone_number) as stored_length,
          CHAR_LENGTH(phone_number) as char_length,
          HEX(phone_number) as hex_value
   FROM users
   WHERE username = 'affected_user';

   If stored_length is longer than expected for the visible number of characters, hidden characters are present.

Solution:

1. In the web interface, delete the phone number field content entirely
2. Type the phone number manually — do not paste
3. Save the user record
4. Test OTP delivery

---

2. Wrong Plus Sign Character

Problem: Phone number uses a Unicode plus sign that looks like + but is a different character.

Root Cause: Different Unicode characters that look like +:

Character	Unicode	Name	Correct?
+	U+002B	Plus Sign	✅
＋	U+FF0B	Fullwidth Plus Sign	❌
➕	U+2795	Heavy Plus Sign (emoji)	❌
﬩	U+FB29	Hebrew Letter Alternative Plus	❌

Solution:

1. Delete the phone number in the web interface
2. Type + from the keyboard (Shift + =)
3. Type the rest of the number
4. Save

---

3. LDAP Phone Number Attribute Mapping

Problem: Phone number retrieved from LDAP/AD is empty, incorrect, or in the wrong format.

Symptoms:

• Users not found in Mideye Server despite LDAP connection working
• Phone number shows as empty
• Phone number has wrong format (e.g., 070-123 45 67 instead of +46701234567)

Solution:

1. Navigate to LDAP Profiles in the web interface

2. Verify the phone number attribute is configured correctly:

   LDAP Attribute	Description	Common In
   mobile	Mobile phone number	Active Directory
   telephoneNumber	Office phone	Standard LDAP
   msDS-cloudExtensionAttribute1	Cloud extension attribute	Azure AD Connect
   Custom attribute	Organization-specific	Varies

3. Verify the attribute value in AD:

   Windows (PowerShell):

   Get-ADUser -Identity username -Properties mobile, telephoneNumber |
     Select-Object Name, mobile, telephoneNumber

   Linux (ldapsearch):

   ldapsearch -x -H ldap://ldap.example.com:389 \
     -D "CN=svc-mideye,OU=Service Accounts,DC=example,DC=com" \
     -W -b "DC=example,DC=com" "(sAMAccountName=username)" mobile telephoneNumber

4. If the phone number in AD is in local format (e.g., 070-123 45 67), it must be updated to international format (+46701234567) in Active Directory.

---

4. Multiple Phone Numbers in One Field

Problem: AD/LDAP attribute contains multiple phone numbers or extra information.

Examples:

• +46701234567;+46709876543 — Semicolon-separated
• +46701234567 (work) — Number with description
• tel:+46701234567 — URI format

Solution:

The phone number field must contain exactly one phone number in international format. Update the value in Active Directory or the web interface.

---

5. Azure AD / Entra ID Sync Issues

Problem: Phone numbers synced from Azure AD (Entra ID) via Azure AD Connect are empty or incorrect.

Common Issues:

• The mobile attribute is populated in Azure/Entra but not synced to on-prem AD
• Azure AD Connect doesn’t sync cloud-only attributes by default
• The attribute used in Azure differs from on-prem AD

Solution:

1. Check which attribute Azure AD Connect syncs:

   # On the Azure AD Connect server
   Get-ADSyncRule | Where-Object {$_.Direction -eq "Inbound"} |
     Select-Object Name, Direction | Format-Table

2. Options:

   • Use msDS-cloudExtensionAttribute1 if phone numbers are cloud-only
   • Configure Azure AD Connect to sync the mobile attribute back to on-prem
   • Manually populate the phone number in on-prem AD

3. Update the LDAP profile in LDAP Profiles to use the correct attribute

---

Diagnostic Workflow

When a phone number validation fails:

1. Check the number in the web interface
   → Does it look correct? (correct format, no spaces)

2. Delete and retype manually
   → Does it work now? → Hidden characters were the cause

3. Check LDAP attribute
   → Is the value in the correct format in AD?
   → Is the right attribute configured in the LDAP profile?

4. Check the database directly
   → Use HEX() to find hidden characters

5. Check the logs
   → What validation error is reported?

---

Bulk Phone Number Analysis

If phone number issues affect many users, identify problematic records:

-- Find phone numbers with unusual lengths
SELECT username, phone_number, LENGTH(phone_number) as len
FROM users
WHERE LENGTH(phone_number) > 16 OR LENGTH(phone_number) < 8
ORDER BY len DESC;

-- Find phone numbers NOT starting with +
SELECT username, phone_number
FROM users
WHERE phone_number IS NOT NULL
  AND phone_number NOT LIKE '+%';

-- Find phone numbers with spaces or dashes
SELECT username, phone_number
FROM users
WHERE phone_number LIKE '% %'
   OR phone_number LIKE '%-%'
   OR phone_number LIKE '%(%';

-- Find phone numbers with hidden characters (length mismatch)
SELECT username, phone_number, LENGTH(phone_number) as byte_len, CHAR_LENGTH(phone_number) as char_len
FROM users
WHERE LENGTH(phone_number) != CHAR_LENGTH(phone_number)
  AND phone_number IS NOT NULL;

---

Phone Number Format Requirements

Requirement	Detail
Prefix	Must start with + (U+002B)
Country code	Required (e.g., 46 for Sweden, 1 for US)
Digits only	No spaces, dashes, parentheses, or dots
Length	8–16 characters total (including +)
Characters	Only + and digits 0-9

---

Getting Help

If phone number issues persist, contact Mideye Support with:

• The phone number that fails (with HEX output if possible)
• The LDAP attribute name configured
• Whether the issue affects one user or many
• Error messages from Log Files