Thank you for contributing!

But why do you want to update a user with the headers? Seems quirky and custom. Can't you override it in your project? Please let us know what this can add to devise token auth that could help other developers.

Would you please explain from line 36 why do we save parameters from request.headers if we do not find it in params on first place:

params[type.to_s] ||= request.headers[type.to_s] unless request.headers[type.to_s].nil?

Params are checked in the case that a user visits an email confirmation link (in which case we can't set any headers). The client should then send the tokens as headers once it's been authenticated.

Does that answer your question @wasifhossain ?

What we can see, params_for_resource is being invoked from the following controllers:

• RegistrationsController: sign_up_params and account_update_params
• SessionsController: resource_params
• PasswordsController: password_resource_params and
• OmniauthCallbacksController: whitelisted_params

with only these 3 resources: :sign_up, :sign_in and :account_update

If we go down further, devise_parameter_sanitizer has the following whitelistable parameters for these resources by default:

devise_parameter_sanitizer.instance_values['permitted']
=>
{
  :sign_in        => [:email, :nickname, :password, :remember_me],
  :sign_up        => [:email, :nickname, :password, :password_confirmation],
  :account_update => [:email, :nickname, :password, :password_confirmation, :current_password]
}

So params_for_resource is basically returning the parameters for whitelisting from the above list, before which it ensures the values for those parameters are in place inside params by first looking up in the params itself, and then in request.headers if it fails in first place. This is what we understand from the line:

params[type.to_s] ||= request.headers[type.to_s] unless request.headers[type.to_s].nil?

At this point, it should be clear that the above code does not look up the authentication headers like access-token etc. but only the above parameters.

So my humble question to @MaicolBen: does not it allow the clients to send the above parameters through headers? and if it does, then this PR would solve issues that I described in the first post.