Skip to content

Instantly share code, notes, and snippets.

@scottybo
Last active May 30, 2018 16:07
Show Gist options
  • Save scottybo/e3bc5403c8fcda2c400d1dbff536604f to your computer and use it in GitHub Desktop.
Save scottybo/e3bc5403c8fcda2c400d1dbff536604f to your computer and use it in GitHub Desktop.
User permissions

Introduction

New to ACL? To learn about Access Control Lists and common terminology, visit: https://en.wikipedia.org/wiki/Access_control_list

TODO

  • Design Kiosk GUI for managing Roles and Permissions
  • Implement GUI using Vue/Blades/Routes/Controllers etc
  • Add seed file for creating default Roles and Permissions
    • System admin (sysadmin)
    • Whitelabel admin (admin)
    • Default user (member)
  • Add seed file for creating Holly Influence Roles and Permissions
    • System admin (sysadmin)
    • Whitelabel admin (admin)
    • Manager (manager)
    • Employee (employee)
  • Create console commands for executing Seeds on whitelabel databases
  • Add GUI to manage User's Roles
  • Add ability to define the Role "authority" so that users can only invite users at or below their Role authority
  • Add ability for newly registered users to be assigned a default Role
  • Make sure all Models that require permissions have an owner_id or user_id column
  • Make sure Bouncer knows about the owner_id column
  • Add ability to check for permissions in Vue components (see: https://medium.com/@sergiturbadenas/how-i-expose-laravel-permissions-in-vue-js-49dd05bedfce) - add a Trait & magic function to output the user's abilities using the Bouncer class instead of the Laravel Permissions class by Spatie
  • Add back-end logic to check for permissions sent via AJAX etc
  • Add role to invitations

Access Control

  • We use Bouncer for managing permissions. Check out the cheat sheet
  • ACL's are applied for Users - we don't have any ACL's for Teams
  • Naming conventions for the permissions will follow the "CRUDIE" accronym (create, read, update, delete, import, export) and take the following format {{create|read|update|delete|import|export}}_{{own|others}}, For example: create_own
  • When ACL permissions are defined, we also define the database Model they apply to, e.g. Bouncer::allow('admin')->to('create_own', Post::class);
  • To check a permission, we simply do $boolean = Bouncer::can('create_own', Post::class);

Seeding the database

  • We have 2 database seeders to automatically populate the default Roles and Abilities/Permissions
    • BouncerSeeder - for standard whitelabels (creates permissions for System Admins, Admins and Members)
    • BouncerInfluencerSeeder - for employee advocacy whitelabels (creates permissions for System Admins, Admins, Managers and Employees)
  • Seeding the core database: php artisan db:seed --class=BouncerSeeder
  • Seeding a specific whitelabel database
    • Standard: php artisan db:seed-whitelabel --database=dbname --class=BouncerSeeder
    • Influence: php artisan db:seed-whitelabel --database=dbname --class=BouncerInfluenceSeeder
  • TODO: Seeding all whitelabel databases. DANGER!!!! php artisan db:seed-all-whitelabel --class=BouncerSeeder

Roles

  • Unlimited Roles can be created (e.g. "Admin", "Social Media Manager", "Customer") via the Whitelabel admin panel
  • Default Roles can be seeded using the instructions above
  • A Role has an authority - this is an integer which allows you to determine how "important" a Role is and decide what they're allowed to do in relation to other Roles. For example, when inviting a User to a Team a Role can be assigned to this user, but the Role that can be assigned should only have equal or less authority than the current user's Role
  • The permission manage_system_roles must be true for a user to be able to manager Roles
  • By default delete_system_roles is only available to System Admins to prevent accidental deletion (which could cause major issues)
  • A User can be assigned multiple Roles
  • If a User has multiple Roles and there is a permission conflict then the true value will always take priority

ACL Objects

Generic

The permissions below are non CRUDIE permissions - they're either true or false and give complete access to a feature. Some features have CRUDIE options, but we don't need to manage them at a granular level. E.g. manage_system_users will give the user full access to create/edit/delete system Users.

  • Example: Bouncer::can('access_system_admin');
  • access_system_admin
  • manage_system_billing
  • manage_system_roles
  • delete_system_roles
  • manage_system_users
  • impersonate_system_users
  • view_system_analytics
  • manage_system_announcements
  • manage_system_calendar_events
  • delete_own_team

Models

  • SocialAccountGroup
    • Example: Bouncer::can('send_to_own', SocialAccountGroup::class);
    • {{CRUDIE}}_own
    • {{CRUDIE}}_others
    • send_to_{{own|others}}
  • ConnectedAccount
    • Example: Bouncer::can('create_own', ConnectedAccount::class);
    • {{CRUDIE}}_own
    • {{CRUDIE}}_others
  • SocialAccount
    • Example: Bouncer::can('create_own', SocialAccount::class);
    • {{CRUDIE}}_own
    • {{CRUDIE}}_others
    • send_to_{{own|others}}
    • refresh_token_{{own|others}}
  • Post
    • Example: Bouncer::can('create_own', Post::class);
    • {{CRUDIE}}_own
    • {{CRUDIE}}_others
  • EvergreenPost
    • Example: Bouncer::can('create_own', EvergreenPost::class);
    • {{CRUDIE}}_own
    • {{CRUDIE}}_others
  • Media
    • Example: Bouncer::can('create_own', Media::class);
    • {{CRUDIE}}_own
    • {{CRUDIE}}_others
    • manage_folders_{{own|others}}
    • manage_system_files_{{own|others}}
    • manage_system_folders_{{own|others}}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment