Read params values from request header in different formats

[wasifhossain]

Currently if the authentication parameters for sign_up/sign_in/account_update are sent in params hash, the values can be parsed and whitelisted without any issue. But if the parameters are set in http header before sending to the api, they are not available in params hash. Then values are looked up in the request header and assigned to params accordingly.

In our case, we sent the parameters e.g. which are required for sign_up (email, password, password_confirmation) in the header from Postman and some other client-side application. But for some reason, params was able to read only the first 2 fields (email and password) and thus creating the user anyway though password_confirmation does not match with password. After some investigation, we found that its available as HTTP_PASSWORD_CONFIRMATION instead of password_confirmation to read from request.headers.

But in specs, if we send the same field in the headers hash, it becomes available with the same name in request.headers. This PR will solve issues in both cases.

[MaicolBen]

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.

[wasifhossain]

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?

[lynndylanhurley]

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 ?

[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.