User and User Account differentiation?

[Benjamin Yu]

Hi,

Can someone explain what the difference is between a User and an
Account in cantango's authorization context?

I have this mental concept that a User is an individual actor in a
system. An Account is a separate entity that "owns" resources in a
system. A User may have membership to an Account... a user may act on
behalf of the account in various ways (probably define by the role the
user takes on in said account)?

Am I off, or way off?

I'm kind of trying to make a mental model of the following example:

An instance of Account may be a conceptual Gym.
One instance of a User will be the "administrator" of said Gym
(Account); takes on the gym_admin role.
Another instance of a User will be a normal member that belongs to the
Gym, and do other things like read news items that was created for
said Gym.

Which permit types should I be using to do something like this? Is
"Account" even the right thing to use?

Thanks,
Ben

[Kristian Mandrup]

A user could potentially have multiple accounts, i.e. a 1-M relationship. This way a user can log into a specific account for some specific context, fx logging into a sub application, such as Admin (admin account) and a normal user account for normal membership content.
For CanTango to use accounts the User model must have an #account method which returns the current account instance.

For your example:

Lets say you have a User model and a GymAccount:

on login in the Gym app, the user.account => GymAccount instance.
You could then define a GymAccountPermit which contains the rules that should apply for any user logged into this account.

class GymAccountPermit < CanTango::AccountPermit
...
end

Then create specific role permits scoped under this account (dynamic roles)

module GymAccountPermits
class AdminRolePermit < CanTango::RolePermit
...
end
end

Does this help?

Kris

[Kristian Mandrup]

Note that I would still have the dynamic roles (#roles_list method) on the User, not on the account.
This way you can define permit rules for the same roles but in the context of a specific account (using account scoping).

[Benjamin Yu]

Thanks, that helps a lot.

-Ben

[Kristian Mandrup]

Another (perhaps better?) approach is to see the devise models generated as the accounts and not the users. 

$ devise UserAccount

$ devise AdminAccount

These accounts would/could then have the username and password

Then generate a "normal" User model, but without username and password. Then a user could have different credentials when logging into a specific account, fx for the Admin account a higher security requirement for the password and so on.

For this to work, you would have to use the account API methods, such as user_account_can? (already available)

This method requires a current_user_account method to be available. 

You could generate these methods like this:

          ::CanTango.config.user_accounts.registered.each do |account|

            base.class_eval %{

              def current_#{account}_account

                current_{account}

              end

            }

          end

 

Now the current_user_account method will proxy to current_user.

There is also a method session_user available, which will retrieve the current_user if present (logged in), and fall back to the guest_user.

        def guest_user

          CanTango.config.guest.user

        end

 

Now when using user_can?, the correct implementation would have to figure out that the current_user method returns an account instance and not a user in this setup. It should in this case call the #user method on this account (from session) to get the user instance. I will try to implement this functionality tonight!

Hell it is a bit complicated to cover all the most common scenarios!

Feel free to come up with more suggestions. The project is best developed with feedback from various developers using it!

Kris