how to do a good rights management

[Orjan]

Hello there!

I'm currently working on an web application
and now I've made the login and registration part and it works great.
now I been thinking for a pretty long time how to make a good rights management part

how do I best store rights in a database?

one thing I've tried has been a string pipeseparared, with values of different rights, with a specific right on a predefined position, but it's hard to manage

before I've saved rights codes in a table, one row for each right to each user and created an rights array from there.

now I'm thinking of these systems and think if this any good at all.

the rights would probably be static, so each rights would be on or off, I don't think I'd lay several levels of rights onto one right, or what can you need?

it needs to be dynamically though, so if I set up a new module into the application, I need to assign new rights for that module...

much to think of, anyone having another solution, or thaugts on my previously used right managements?

the system needs to be easy to handle both in reading from database and easy to update in great sets from the coming admin panel.

I will probably need to set up a list of possible rights too, so the admin panel can read out of a list how to know what to let control or not..

[Jordan]

If you do not want to store each one in a separate column, each right that is, you can use the serialize and unserialize functions of PHP do basically do what you described earlier.

Serialize:
Returns a string containing a byte-stream representation of value that can be stored anywhere.

Unserialize
unserialize() takes a single serialized variable and converts it back into a PHP value.


How many rights are there? If it were me I'd make a new table using the ID (which would link back to the user and be the identifier) and have a new column for each right. The right would contain an integer value of 0 or 1.

[Orjan]

the problem is that I will have more rights to set for each module added, so I can't have it column based, as I don't want a new module to change the base data structure, only the data structure it self will need in case of tables and so.

it might be everything from 5 to 500 different rights all depending of how many modules are added in the future...

I will look into the Serialize thingie and see what that gives.

[Orjan]

yepp, Im bumping this thread, as I can't find a good solution on this by my self, and hope that anyone out there might have an advice for me.

I at the moment feel like I can't run further with the system I'm writing, before I know how to handle the rights part, as it is rather important and decisive for the future of the framework I'm writing.

[WingedPanther]

The real question is this:
Can you define a few basic levels, or does it have to be on a per-user basis?

[Orjan]

it really have to be on a per-user level, so everyone could have a special setup of rights, except for a few admins who shall have it all.

[MeTh0Dz]

If it were me and I had to do it that way. I'd make a structure of rules, and then for each user just save that structure in a database.

[Orjan]

yes, that is the question, how to do a working structure and storage of it, both easy to read, write and modify from my code?

is it better to make boolean rights for each use, or should i make fewer with a certain level?
like:

booean type generates this kinda rights:
read page A
modify page A
alter page A
whatever page A

or the level based of
Page A: read, modify, admin etc with increasing rights...

the first one take more out of the db, with storage and looping etc,
but is really simpler to work with, I guess?

or the second way which is easier with the db, but would need more logic in the code
to interpret the rules.

and, if you go with boolean type, should I store all rights with true or false, or just the set ones? what would be easiest? what would be better in a coding example, how to check if a right is ok or not etc?

it's many questions, ofcourse some, Ieed to just decide much depending on my code, but it is still a few ways to go depending on what makes logical and usable.

[WingedPanther]

Perhaps a bit-string to store the permission/denial values.