Postponed (maintainer needs more info)
Project:
Drupal core
Version:
main
Component:
user system
Priority:
Major
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
7 Feb 2024 at 15:41 UTC
Updated:
22 Dec 2025 at 19:08 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
cilefen commentedThis is very particularly like #3415582: Unhandled exception when trying to register a duplicate username with different case.
Comment #3
larowlanComment #4
larowlanWas expecting this would also impact username, as it also uses that constraint - but we have a unique key on name for the users table, so instead if causes a fatal (SQL) exception - so still an issue.
Added tests and fix for both cases.
Comment #5
divya.sejekan commentedComment #6
Paras Awasthi commentedI am new here, can I work on this issue?
Comment #7
divya.sejekan commentedI verified for the use cases given above. The fix is working - Error message are displayed 'The email address EMAIL@TEST.COM is already taken.'
Testing Steps :
1. Creating user with Email@test.com
2. Verify when used different cases such as eMail@test.com , EMAIL@test.com - error message must be displayed
3. Verify when used same case Email@test.com with different usernames - - error message must be displayed
Can be moved to RTBC++
Keeping this in need review for further reviews.
Comment #8
divya.sejekan commentedComment #10
smustgrave commentedOpened an MR and appears to have test failures.
Comment #11
longwaveAdded a question to the MR.
Comment #12
larowlan#3415582: Unhandled exception when trying to register a duplicate username with different case is in so let's repurpose this
Comment #13
larowlanComment #14
larowlanComment #15
caesius commentedThis appears to have been added in the latest core security update:
https://www.drupal.org/sa-core-2024-004
https://git.drupalcode.org/project/drupal/-/commit/f1d3470b057e84fd5483b...
Comment #16
cilefen commentedIs this fixed in total by the security release?
Comment #17
jamsilver commentedA comment here that may save others time.
Today, I added the
UniqueFieldconstraint onto a base field on a custom entity type, settingcaseSensitiveto TRUE, and found that it did not work. I created a new entity and entered a value for this field that matched an existing value, except for a change in the case of a single letter (e.g. "bar" vs "Bar"). This validator rejected the new entity. but I would have expected it to accept it.As it happens, my field is a
stringtype, and I was able to fix this by setting thecase_sensitivefield option to force the SQL field storage to store it in a format that always behaves case-sensitively in queries. All in all, this is the sort of base field definition I now have:It may be relevant that I'm using MariaDB (version 10.4) rather than MySQL.
On balance this feels to me like unexpected behaviour in the
UniqueFieldConstraint that should be improved. There's nothing in the documentation of thecaseSensitiveoption that indicates extra steps are necessary in the SQL storage to make it work.The UniqueFieldValueValidator uses an entity query, and entity query has supported case-sensitive comparisons since #2068655: Entity fields do not support case sensitive queries. Perhaps a better implementation here would be to keep the OR condition when caseSensitive, but use an operator like
LIKE BINARY?Comment #18
smustgrave commentedWanted to bump this 1 more time if still relevant.