split responsibilities of acts_as_token_authentication_handler_for method

[mtoygar]

as far as I understand acts_as_token_authentication_handler_for does 2 things. First, it does add authenticate_#{entity.name_underscore}_from_token method. Second, uses one of these methods as a controller filter.

This approach becomes a problem when an app supports more than one authentication method. Our app needs to decide the authentication method using the headers on the request. We have a filter with the name authenticate_user_with_multiple_system!. This method actually authenticates the user either with JWT, doorkeeper or devise. However when we use acts_as_token_authentication_handler_for method another filter is automatically added. I believe that the api of this gem would be more flexible and beneficial if acts_as_token_authentication_handler_for method only defines the filter hooks and application developer use the filter method explicitly later on.

Below I share a code snippet to demonstrate the auth logic with more than one authentication method

def authenticate_user_with_multiple_system!
  if valid_doorkeeper_header?
    # auth with doorkeeper
  elsif valid_devise_header?
    # auth with devise
    # use `authenticate_user_from_token` method here
  else
    # unauthorized
  end
end

With the current API authenticate_user_from_token or authenticate_user_from_token! methods runs no matter what. We can skip it using skip_before_action but I believe that using authenticate_user_from_token directly is way more explicit.

My current workaround (Actually I dont try this yet but I believe that it should work)

skip_before_action :authenticate_user_from_token # or authenticate_user_from_token! depending on the fallback
before_action authenticate_user_with_multiple_system!

[mtoygar]

this is the copy of #379. When I see that discussions are also set up for the repo I decided to migrate it to here

[gonzalo-bulnes]

Hi @mtoygar!

Thank you for moving this to discussions, I think that's indeed an appropriate place : )

Your is an interesting user case, my first thought was indeed that you could skip authenticate_user_from_token if yo want to call it explicitly elsewhere. And I too expect your code snippet to work. (Let me know if it doesn't!)

If I'm understanding your suggestion correctly, we'd be changing the default behavior and requiring people to explicitly set up the before filter/action in their controllers, am I correct? If that's the case, as much as your use case is a legitimate and perfectly valid use case, it is not the most common use case, and I believe that the defaults should cover the most common use case instead.

The options of skipping authenticate_user_from_token (despite adding one line to your controller) seems fairly reasonable, doesn't it? Are there other consequences that I'm missing?