Q: Authenticating two models in one controller (R: One handler each; fallback_to_devise disabled for the first.)

[TomNaessens]

I have a use case where I have two models: a Devise-CAS-authenticated User and a token-authenticated Partner. The user should be able to crud partners, while a partner is only allowed to show his page and post to a custom controller action.

I was thinking something along the lines of:

class PartnersController < ApplicationController

    acts_as_token_authentication_handler_for Partner
    before_action :authenticate_partner!, only: [:show, :confirm]
    before_action :authenticate_user!

    [controller actions]
end

The problem here however is that when I navigate as an authenticated User to the index method, my access gets denied. This is because (correct me if I'm wrong) the acts_as_token_authentication_handler already includes the before_action authenticate_partner! as a fallback if the token authentication fails, causing the authentication to fail, and throwing the 403 error.

Is there a way around this or is it possible to restrict the acts_as_token_authentication_handler to certain controller actions?

Thanks in advance.

[TomNaessens]

At the moment, I used a workaround where I have a different controller which logs in the partner and redirects the partner to the partner show URL. Using the sign_in_token = true, the acts_as_token_authentication_handler does not need to be placed on top of the original controller.

It may however still be an interesting use case to allow scoping for this method, so I'll leave this open.

[gonzalo-bulnes]

Hi @silox, seems you're right about the access denied causes; I'm AFK right
now ; )

[gonzalo-bulnes]

Hi @silox, I'm sorry I haven't replied to you sooner.

The use case you want to implement is quite complex. In fact, my first idea in such a case would be either to treat "User" and "Partner" as roles with a single User model, or to implement them as two sub-classes of an unique token authenticatable class (typ. through Single Table Inheriance). In that last implementation, I would probably name their parent class Account or User, while the children could be PartnerAccount/UserAccount or CustomerPartner/Customer... there are a bunch of possibilities depending on your business. I didn't knew about CAS, and I don't know if it can interfere with such a design.

On the other hand, it should be possible to allow passing the only: [:show, :confirm] option to acts_as_token_authenticatation_handler. However, since that option won't affect the method itself but authenticate_resource!, I'm not sure about which syntax could avoid ambiguity.

A third way could be allowing to disable, through an initializer option, the authenticate_resource! calls. That would delegate to you to call it after each acts_as_authentication_handler decalaration. I don't like very much this possibility because of the importance of that call (remember the Access Forbidden is finally ensured by Devise, not by Simple Token Authentication). Yet it could be considered.

[gonzalo-bulnes]

Hi @silox, taking about making the authenticate_resource! calls optional, I think the last part of this comment may interest you.
We still would have to define how that would interact with the eventual :only options, but that may simplify your issue.

Regards!

[TomNaessens]

👍

[gonzalo-bulnes]

Hi, keep an eye on #66.

[gonzalo-bulnes]

Since v1.5.0 the #66 feature is implemented and examples can be found in the Installation section of the README file.