After upgrade to 2.2.0, NoMethodError: undefined method `email' for

[3dd13]

I am using the authentication_keys in my model which does not have email field.

  devise :database_authenticatable, :token_authenticatable, :authentication_keys => [:full_phone_no]

the error is thrown when I create an instance. stacktrace:

gems/activerecord-3.2.11/lib/active_record/attribute_methods.rb:149:in `method_missing'
gems/devise-2.2.0/lib/devise/models/authenticatable.rb:173:in `apply_to_attribute_or_variable'
gems/devise-2.2.0/lib/devise/models/authenticatable.rb:165:in `block in downcase_keys'
gems/devise-2.2.0/lib/devise/models/authenticatable.rb:165:in `each'
gems/devise-2.2.0/lib/devise/models/authenticatable.rb:165:in `downcase_keys'

the error should be because the line authenticatable.rb:163

def downcase_keys
  self.class.case_insensitive_keys.each { |k| apply_to_attribute_or_variable(k, :downcase!) }
end

so, to make it working in the latest version 2.2.0, I have to clear out config.case_insensitive_keys

# default
# config.case_insensitive_keys = [:email]
config.case_insensitive_keys = []

is it expected behavior ?
should we include it in the wiki or upgrade notes ?

[josevalim]

No, this is a bug, thanks for reporting! And you likely do not want to clear your case_insensitive_keys. Could you please provide an application that reproduces the error? (ours are working fine).

[jamesalmond]

I think I'm experiencing this bug too. It's in an app with two separate user models that have different authentication_keys.

Previously I had the following in initializers/devise.rb:

config.case_insensitive_keys = [ :email, :username]

which didin't cause problems before the upgrade. Now it seems to be trying to downcase the username field on the user model that uses the email field.

As a temporary solution I've put the configuration on the models directly:

devise :database_authenticatable, authentication_keys: [:email], case_insensitive_keys: [:email]

and commented out the config in initializers/devise.rb

[lucasmazza]

I believe this is a regression from #2135, thanks to apply_to_attribute_or_variable usage of send.

>> user[:foo]
=> nil
>> user.send(:foo)
NoMethodError: undefined method `foo' for #<User:0x007fb4c2d835f0>

[latortuga]

@lucasmazza author of #2135 here, I actually had a check with respond_to? before calling send in there before. Would you like me to put it back?

I actually think it makes sense that it blows up: why would you configure globally that you want email to be case-insensitive if you only want it for one model? However, that view may be at odds with how you guys want it to work. I'm happy to submit a PR with a fix.

[jamesalmond]

@latortuga when I found this issue I did start to question why my config was setup up this way. I think it makes more sense to be defined on a per-model basis as you say (I'd already set the authentication_keys per-model).

As it just happened to work (and it's not always obvious how to deal with multiple models in devise) I didn't question it at the time as I assumed having the keys set on each model would mean only the relevant keys get checked. I think this was an incorrect assumption on my part.

[3dd13]

@latortuga
I agree with @jamesalmond

I thought it was something wrong because it wasn't working after upgrade.
but actually it was the way that I customized the authentication_keys per model.

so, now the question is ... how do we want coder to customize per model authentication keys ?

choice 1:
devise take authentication_keys as a more reliable list of fields.
and then everytime devise do things with keys, it should cross check with the list of authentication_keys of that model

choice 2:
let coders handle all the key list carefully.
and we have a more formal wiki article teaching coders to do it right.

?

[lucasmazza]

Besides the discussion if the configuration should be done globally or not, I think we first need to fix this and retain the expected default behavior of Devise, so upgrades from 2.1.x to 2.2.x won't blow things up. So @latortuga please send a PR fixing this ❤️.

[josevalim]

The fact it worked previously was an accident. That I oversaw. Sorry everyone.

@lucasmazza is correct, we should fix this regardless. @latortuga, I would appreciate if you could send a fix, if not, let me know and I will get around it.

Thanks everyone!

[latortuga]

@josevalim I've got a fix written with a failing test. Will submit it shortly.

[josevalim]

Guys, a fix was merged to master. Can you please give it a quick go and let me know if it works?

Thanks a ton @latortuga !!!