how do you all store the roles?

[laptopmutia]

currently I have an array field on my model and using user.roles.includes?("rolename") to check if they have access or not

[palkan]

Usually, I design the authorization model on top of permissions and roles. Permissions are granular and describe business logic restrictions, e.g., "manage_projects", "view_projects", "manage_users", "view_users", etc. Roles act as permission sets and only used to assign typical permissions for users.

Permissions can be stored in an array or JSONB field (I prefer the latter):

class User < ApplicationRecord
  attribute :permissions, Permissions::Type.new
end

User.new.permissions #=> Permissions::Set

# Roles only used to synchronize permissions
user.permissions = role.permissions

In policies, we check for permissions, not roles:

class ApplicationPolicy < ActionPolicy::Base
  # add permissions accessor
  delegate :permissions, to: :user
  # allow everything to adnins by default
  pre_check :allow_admins!

  private

  def allow_admins!
    allow! if admin?
  end
end

class UserPolicy < ApplicationPolicy
  pre_check :ensure_same_account!, only: :show?

  def show?
    permissions.view_users?
  end

  private
  
  def ensure_same_account!
    deny! unless record.account_id == user.account_id
  end
end

[laptopmutia]

hi its been a while but I got confused about this part

class User < ApplicationRecord
  attribute :permissions, Permissions::Type.new
end

what is this Permissions::Type.new and that line of code meaning?

and for the condition check on the policy models

why your example is just as simple as this permissions.view_users?

is there any relations about it and the attribute line code on the User class?

is it some kind of hash to object transformation or something?

[laptopmutia]

I think its kinda related with this post https://evilmartians.com/chronicles/wrapping-json-based-active-record-attributes-with-classes

[palkan]

Yeah, it's a custom active record type. The main reason why we use a custom type is to support updating permissions by updating the object and compact the database representation (so you can have some short identifiers instead of full permission names).

[laptopmutia]

any example of controller codes for roles modification that using jsonb? I also wonder how the strong parameters and the views looks like

…

On Thu, May 18, 2023, 6:52 AM Vladimir Dementyev ***@***.***> wrote: Usually, I design the authorization model on top of permissions and roles. Permissions are granular and describe business logic restrictions, e.g., "manage_projects", "view_projects", "manage_users", "view_users", etc. Roles act as permission sets and only used to assign typical permissions for users. Permissions can be stored in an array or JSONB field (I prefer the latter): class User < ApplicationRecord attribute :permissions, Permissions::Type.newend User.new.permissions #=> Permissions::Set # Roles only used to synchronize permissionsuser.permissions = role.permissions In policies, we check for permissions, not roles: class ApplicationPolicy < ActionPolicy::Base # add permissions accessor delegate :permissions, to: :user # allow everything to adnins by default pre_check :allow_admins! private def allow_admins! allow! if admin? endend class UserPolicy < ApplicationPolicy pre_check :ensure_same_account!, only: :show? def show? permissions.view_users? end private def ensure_same_account! deny! unless record.account_id == user.account_id endend — Reply to this email directly, view it on GitHub <#246 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKKFOTN4ICJ3WHAVIH5SVZLXGVQDLANCNFSM6AAAAAAX4PA3DU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[palkan]

Here is an example of configuring strong parameters:

params.require(:user).permit(:email, :name, permissions:  [Users::Permissions.public_keys])

Where User::Permissions is a model carrying all the information about possible granular permissions; public_keys returned the permissions that can be managed by users (there were also some private permissions, like admin).

A client or form submits a hash in a form {"permissions": { "manage_users": true }} (all permissions must be specified, not only changed).

[laptopmutia]

| (all permissions must be specified, not only changed)

means all the permission that is returned by public_keys right?

[palkan]

I meant all permissions you want a user to have, not only the one you want to change