You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
defauthenticate_user_with_multiple_system!ifvalid_doorkeeper_header?# auth with doorkeeperelsifvalid_devise_header?# auth with devise# use `authenticate_user_from_token` method hereelse# unauthorizedendend
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 fallbackbefore_actionauthenticate_user_with_multiple_system!
The text was updated successfully, but these errors were encountered:
as far as I understand
acts_as_token_authentication_handler_for
does 2 things. First, it does addauthenticate_#{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 useacts_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 ifacts_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
With the current API
authenticate_user_from_token
orauthenticate_user_from_token!
methods runs no matter what. We can skip it usingskip_before_action
but I believe that usingauthenticate_user_from_token
directly is way more explicit.My current workaround (Actually I dont try this yet but I believe that it should work)
The text was updated successfully, but these errors were encountered: