• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Authorization and per-subproject roles assignment (Myth::Auth?)

#1
I work on a service that allows creating per-company boards:

  1. Boards look the same for each company
  2. Company board data is 100% independent from other companies (could be even separated DB)
  3. Users can have access to multiple boards (with various roles)
Example:


Code:
┌─────────┬────────────────┬────────────────┬────────────────┐
│  User   │ Company A role │ Company B role │ Company C role │
├─────────┼────────────────┼────────────────┼────────────────┤
│ John    │ Admin          │ Admin          │ –––            │
│ Michael │ –––            │ User           │ –––            │
│ Bill    │ User           │ –––            │ Admin          │
└─────────┴────────────────┴────────────────┴────────────────┘

Can you recommend any authentication & authorization solution I could use to cover above requirements?




I really like Myth::Auth thanks for its design and CI integration but I'm not sure how to use it properly to support above.

I was thinking about creating groups and permissions for each company but that would be cumbersome to have groups/permissions like:
  • "company-a.admins"
  • "company-a.users"
  • "company-b.admins"
  • "company-b.users"
Reply

#2
Check out Tatter\Permits on Packagist. This is precisely the point of it: allowing object-level permissions. It is designed to take chmod/POSIX style modes for each table, including optional user and group ownership definitions.

https://github.com/tattersoftware/codeigniter4-permits

I should add that it meshes nicely with Myth:Auth for the actual authentication piece.
Reply

#3
Why Auth and Permission in 2 other packages?
Auth must full and in only one package!

Myth Auth in dev, but must have full basic features, developer should think about that...
For users only use one package for user, role, permission

Learning CI4 from my works, from errors and how to fix bugs in the community

Love CI & Thanks CI Teams

Reply

#4
(11-07-2020, 04:54 PM)MGatner Wrote: Check out Tatter\Permits on Packagist. This is precisely the point of it: allowing object-level permissions. It is designed to take chmod/POSIX style modes for each table, including optional user and group ownership definitions.

https://github.com/tattersoftware/codeigniter4-permits

I should add that it meshes nicely with Myth:Auth for the actual authentication piece.
Thanks for reply @MGatner!

Interesting project, I could only wish it had some extra documentation (and examples) for extending it. For people who need more than read and write flags only. I'll check the code in any case.

From what I see Tatter\Permits focuses on per-model's-object permissions. I don't need such a detailed access control. Do you think below would be fair Tatter\Permits usage for my case?
PHP Code:
use CodeIgniter\Controller;

class 
CompanyCustomers extends Controller {
    public function index()
    {
        $companies = new CompaniesModel();
        $customers = new CompanyCustomersModel();

        $companyId $this->session->get('company_id');

        $company $companies->find($companyId);
        if (!$company->mayList()) {
            return redirect()->to(site_url('/'));
        }

        return view('index', [ 'customers' => $customers->where('company_id'$companyId)->findAll() ]);
    }

Reply

#5
@rmilecki Almost! `mayList()` is a model function - you can think of it like a directory: "Can the current user list files in this directory?" In your example above you probably want `if (! $company->mayRead())` - equivalent to "Can the current user view this specific file?"

Docs and examples are definitely on the list, but there's a lot of raw content I still need to create for the framework itself and these modules before I come back to some of the refining. I would love some community help, so if you find this module useful and want to make some recommendations or PRs please do! Even just hearing about what is confusing can be useful.

(11-08-2020, 02:42 AM)nc03061981 Wrote: Why Auth and Permission in 2 other packages?

I see no reason why that should be the case. Permits was designed specifically to work with another package for Authentication and general user Authorization, with Myth:Auth specifically in mind. The type of authorization offered by Permits is rather unique and not going to be applicable to as many projects as something like Myth:Auth. At the same time it would be silly to rewrite all the authentication code just to keep it "under one roof".
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2021 MyBB Group.