Using devise 4.3.0, the comments in Devise.setup are these:

  # Configure which authentication keys should be case-insensitive.
  # These keys will be downcased upon creating or modifying a user and when used
  # to authenticate or find a user. Default is :email.
  config.case_insensitive_keys = [:email]

We noticed that the downcasing (lowercasing) occurs during the validate of the model. It was unexpected to have such a data-altering side-effect in a validate (and it causes mixed-cased emails to be saved as-is to the database in some cases). This means that downcasing is not applied if validation is skipped, e.g.

• user.save! <-- the email is downcased
• user.save(validate: false) <-- the email is not downcased
• user.update_attribute(:email, "[email protected]") <-- the email is not downcased (because update_attribute skips validation)

I searched https://github.com/heartcombo/devise for case_insensitive_keys to see if the fact that downcasing is applied on validate was documented, and if that was still the case in recent versions, and didn't find anything yet.

Does the parameter "case_insensitive_keys" downcase the keys during validate in recent devise version, and if not which version fixed this, and at which stage is the downcase done now (and are there still contexts in which devise's downcasing of the keys would not be applied inside Rails)?

CodePudding user response：

Following @engineersmnky's comment, at the time of writing, devise downcases the keys during a before_validation. It has done so since 2011 (it was done before_save before the fix for this issue).

before_validation is not run when validation is skipped, as others have pointed out (e.g. here and here), which can result in devise allowing duplicate keys, such as emails, in the database (e.g. [email protected] and [email protected]), even though the configuration has config.case_insensitive_keys = [:email].

Skipping validation may occur in more circumstances than the two listed in the question. This Google search can provide a starting point to find out which type of code can result in skipping the validation.