`auth.emailSignUp(...)` API call sends unnecessary `confirm_success_url` param

[Aerlinger]

In Rails this will trigger an UnpermittedParameters exception on the backend:

Here's the code to reproduce:

$.auth.emailSignUp({
      email: email,
      password: password,
      password_confirmation: password
    }).then(function (res) {
      console.log("SUCCESS", res)
    }).fail(function (err) {
      console.log("FAIL", err)
    });

params sent in POST request

email:[email protected]
password:iamsecret
password_confirmation:iamsecret
confirm_success_url:http://127.0.0.1:5000/

Exception on backend:

ActionController::UnpermittedParameters (found unpermitted parameter: confirm_success_url):

actionpack (5.0.2) lib/action_controller/metal/strong_parameters.rb:733:in `unpermitted_parameters!'
actionpack (5.0.2) lib/action_controller/metal/strong_parameters.rb:397:in `permit'
devise_token_auth (0.1.40) app/controllers/devise_token_auth/registrations_controller.rb:101:in `sign_up_params'
devise_token_auth (0.1.40) app/controllers/devise_token_auth/registrations_controller.rb:199:in `validate_sign_up_params'

Obviously, it's possible to whitelist the confirm_success_url param, but does it need to be there in the first place?

[hughkolias]

It's sent because devise_token_auth requires the confirm_success_url param (see https://github.com/lynndylanhurley/devise_token_auth#initializer-settings).

Maybe we could make it over-ridable in jquery.j-toker.js (it's being set at line 652 [opts.confirm_success_url = config.confirmationSuccessUrl();]), and let people set the confirm_success_url in the devise_token_auth initializer instead of whitelisting the param?

Not sure if people would find this useful though?

[moyuanhuang]

devise_token_auth v0.2.0 is said to have this issue. I was able to get rid of it by reverting the version to 0.1.43.