Hardcoded resource.provider in RegistrationsController?

[m4-miranda]

The resource.provider field in Registrations#create is hardcoded to 'email'. Shouldn't this be obtained from Devise?

I'm trying to get rid of email dependency altogether

[zachfeldman]

Hey @m4-miranda sure, I agree with your logic here. Mind opening a pull request to illustrate your exact changes in mind?

[MaicolBen]

If you make a PR, you can reuse the provider method defined in #975

[m4-miranda]

@MaicolBen It isn't possible to override the concern, is it? I could modify the get_resource method to accept a provider parameter, but the method would have to be declared in each controller

[MaicolBen]

You can override it in your code, and yes, you have to do it in every controller (you can make a concern in your code to avoid repeating)

[MaicolBen]

Closed via #998

[KelseyDH]

This gotcha really screwed me up. It would be really nice for provider not to be hardcoded in these controllers as a default e.g. perhaps by checking first if its defined from params before hardcoding it to email?

This way I could add 'provider' as a permitted param to configure and use it as I wish with expected behaviour.

I lost many hours trying to figure out why my user model kept hardcoding provider to 'email'. Similar to email_changed? we should try to find ways of implementing devise without creating these crazy overrides, as they make for very hard to debug and confusing behaviour when custom behaviour to our User model is added.

[MaicolBen]

Sorry to hear that, as we don't have a lot of code documentation, you need to read the source code, in case of the provider, you can override with what was defined in #975

[KelseyDH]

@MaicolBen Thanks for getting back. My intention is to have provider switch between username and email based on the params received within the same controller. Any idea on how I could go about implementing that kind of dynamic override for the registrations controller -- and not have this hardcoded provider:

def provider
  'email'
end

unexpectedly modify and break my User model elsewhere on subsequent updates to a user (like password resets or logins)?

(Overall I'm skeptical why this code was moved into a concern at all, as it seems to make extensibility and customization of each controller more unclear and difficult.)

[KelseyDH]

I tried modifying the gem to override the registrations controller code from something like this:

module DeviseTokenAuth
  class RegistrationsController < DeviseTokenAuth::ApplicationController

    def create
      @resource            = resource_class.new(sign_up_params.except(:confirm_success_url))
      @resource.provider   = provider

over to this:

module DeviseTokenAuth
  class RegistrationsController < DeviseTokenAuth::ApplicationController
 
    def create
    @resource            = resource_class.new(sign_up_params.except(:confirm_success_url))
    if sign_up_params[:provider].present?
      @resource.provider = sign_up_params[:provider]
    else
      @resource.provider = provider
    end

but it didn't work and I still get back an email provider in my model despite explicitly sending in params for "provider" => "username" and explicitly whitelisting the param provider in my devise_sanitizer for sign_up. It is my hope that something like this could fix the gem to provide more expected behaviour when provider is customized.

[MaicolBen]

That's happening because you aren't saving the provider in the resource, which it isn't a good solution. I believe this has been worked on #990, but we need it finished in order to use it. In fact, we put a bounty on it in order to get it ASAP