FuelPHP Forums

andersoncdz

Hello there,

I am currently starting a project where the registered users will belong to a company. As a start I created a company table and a user’s field connecting it to the company.

My biggest question now is separating the access rules (ACL) by company, for example: when a user belongs to a group and this group has defined access rules. In my case each company will have its own groups and users and also use its own access definitions.

I would like to know which would be the best way to do that using fuel PHP.

It will be necessary to have an account that is able to see all the registered companies and their settings, in this case I would like to know if anyone has a suggestion to make this separation possible.

Thank you

Harro

You mean like a multi-tenancy setup? With possible "admins" per company?

We have one app in maintenance with something like that (not ACL, but mutli-company data), and in that app it is solved by adding the company_id to the relevant tables, and a "where-condition" in the model (defined on relations) which basically act like a filter.

A "where-condition" basically adds a "AND company_id = nnn" to every query generated by the ORM which makes it transparent for the code.

Alternatively you could do this in code (add a where clause to queries) which would archieve the same result, of even combine the two.

For us it was more transparent than using seperate tables per company, or prefixing values (instead of "groupname" use "company-groupname" and filter on that.

andersoncdz

Thanks for your answer, Harro.

What you asked is correct, it is about a multi tenancy setup.

Your suggestion to use the company_id is in fact something I have already started doing. When it came to adding the company_id field on the tables that FuelPHP uses as an access control it occurred to me how it would be possible to change it so that the Authentication package would use the company_id to make the data for each company.

Following your recommendations on previous questions I have made I wouldn’t like to alter the original files in FuelPHP, although I couldn’t understand how I could extend the classes from the authentication package.

Thank you for answering and for the presented ideas.

Harro

I see your issues.

Adding the column to the model properties isn't that complicated, that is a simple class extension in the app which won't interfere with the Auth code.

There is some discussion about ORM filter conditions on relations at the moment.

It might be worthwhile to look into filter conditions on the model itself as well, so you can define it on the model, and make it transparent for every query you run against it.

andersoncdz

Thank you very much, Harro,

After your last post I have been looking into Auth package and trying to overwrite the model classes using Bootstrap, as I have already done in certain ocasions.

I would like to know if you could give me a direction on how to do classes extensions and if I'm going on the right direction using Bootstrap to extend classes on Auth package.

I'm sorry I didn't understand the explanation about the conditions' filter, actually I got more doubts because looking at the code I noticed Auth uses cache to grab permissions, I just didn't get at what moment those caches are created. I have already created the company_id field on the tables used in Auth.

While I was looking at Auth's models I noticed the table_through is null within the relation many_many, I would like to know what happens in that case, if it's not too much trouble. I just got curious about it.

Thanks a lot for your attention

Harro

The caches are created once the permissions are computed, and reset when an update is made. If you update the data outside of Auth, you need to flush the cache yourself after you made an update.

Calculating effective rights is complex and time consuming, which is why it is cached.

As to extension, there are two possible routes.

You can overload any Fuel class in app/classes, and that includes the Auth classes. Just make sure you use the same paths and class names.

You can also extend any Fuel class in app/classes.

We have an app that does both:

Autoloader::add_classes(array(
   // our custom auth classes
   'Auth_Login_Customauth'        => APPPATH.'classes/auth/login/customauth.php',
   'Auth_Acl_Simpleacl'        => APPPATH.'classes/auth/acl/simpleacl.php',
));

This app overloads the Auth_Acl_Simpleacl class, and extends the Auth_Login_Simpleauth class.

Conditions are mentioned in the configuration section in the docs: https://fuelphp.com/dev-docs/packages/orm/relations/intro.html#/intro

You define them on the relation in the model, and they work as a built-in where clause. So if your Model_A model has a condition on the "modelb" relation like this:

'condtion' => array(

'where' => array(

'client_id' => 1,

),

and you do

$result = Model_A::query()->related('modelb')->get();

the query will be something like

SELECT * FROM modela LEFT JOIN modelb ON modelb.id = modela.modelb_id AND modelb.client_id = 1

So you'll never see Model_B records in your result with client_id's other than 1.

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.

Howdy, Stranger!

Categories

In this Discussion