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

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.

from simple_token_authentication.

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

from simple_token_authentication.

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.

from simple_token_authentication.

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!

from simple_token_authentication.

👍

from simple_token_authentication.

Hi, keep an eye on #66.

from simple_token_authentication.

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

from simple_token_authentication.