4 ms·

I smell over-engineering. It sounds like you would like to keep your authorisation logic nicely decoupled from your code, stored away in a database. As you are

I smell over-engineering. It sounds like you would like to keep your authorisation logic nicely decoupled from your code, stored away in a database. As you are starting to notice, you can only get so far with that approach and as you try to make your configuration more powerful to handle more and more edge cases, you will inevitably end up with some sort of Turing complete configuration system. My advice is to stick with something simple and just hard code the edge cases in your code. It may feel dirty but at least you won't end up with a monster like AWS IAM in your side project.

ironchef 11y ago
And you basically laid out a recipe for incurring technical debt. What's wrong with instead looking at some established best practices / suggestions and using those for guidance. What if they said they were looking to do this with encryption? Would you say "Just hash it with ROT-13 and put it in the DB"? Of course not. Others have gone before us...why not learn from where they've done well and not so well?
- btilly 11y ago
  Others have gone before us...why not learn from where they've done well and not so well? I have looked at that, and I have learned from both them and experience that authentication and authorization tends to turn into a rabbit hole that takes a lot of effort for very little return. You can do a surprisingly long time with a simple approach, and for most people it isn't worth trying to consider doing anything else.
- olalonde 11y ago
  What I am recommending is an established best practice: YAGNI or perhaps KISS. When I meant something simple, I didn't mean to throw away the whole authorisation abstraction. I do consider things like role/permission based authorisation relatively simple as long as the whole logic doesn't live in a database a la http://blog.bronto.com/wp-content/uploads/2014/10/imagecache/blog-full-colum/magento-21.png http://blog.bronto.com/wp-content/uploads/2014/10/imagecache....
  - ironchef 11y ago
    Ok. I guess the difference is I would never suggest RBAC to be "relatively simple". There are so many considerations (are negative permissions required? are there many to many required? separation of duties?) that without making things explicit it's hard to know what is meant by "role/permission based authorisation".
jimjimjim 11y ago
I guess it depends on the size of the project/site/page but the system of users roles and rights doesn't have to be complex and can provide a good amount of flexibility. It can be as simple as one more table in the db and a couple of lookups or a join.
keth 11y ago
Your sense of smell might be on point here. I dont know. But I've noticed that I tend to sometimes over-engineer things. Maybe because I did the exact opposite in the past and had to rewrite large parts of a hobby project because it was to tightly coupled. Took a while to answer because apparently I submit my comments too fast. :O
OrionSeven 11y ago
I tend to agree with olalonde. What you've described is a well accepted method to handle authorization (sounds like you've implemented role-based access control). But for things like, can't delete yourself, etc., those in my mind are business rules and not authorization rules. In fact that's a validation rule and not authorization rule.

ironchef 11y ago

And you basically laid out a recipe for incurring technical debt. What's wrong with instead looking at some established best practices / suggestions and using those for guidance. What if they said they were looking to do this with encryption? Would you say "Just hash it with ROT-13 and put it in the DB"? Of course not. Others have gone before us...why not learn from where they've done well and not so well?

btilly 11y ago
Others have gone before us...why not learn from where they've done well and not so well? I have looked at that, and I have learned from both them and experience that authentication and authorization tends to turn into a rabbit hole that takes a lot of effort for very little return. You can do a surprisingly long time with a simple approach, and for most people it isn't worth trying to consider doing anything else.
olalonde 11y ago
What I am recommending is an established best practice: YAGNI or perhaps KISS. When I meant something simple, I didn't mean to throw away the whole authorisation abstraction. I do consider things like role/permission based authorisation relatively simple as long as the whole logic doesn't live in a database a la http://blog.bronto.com/wp-content/uploads/2014/10/imagecache/blog-full-colum/magento-21.png http://blog.bronto.com/wp-content/uploads/2014/10/imagecache....
- ironchef 11y ago
  Ok. I guess the difference is I would never suggest RBAC to be "relatively simple". There are so many considerations (are negative permissions required? are there many to many required? separation of duties?) that without making things explicit it's hard to know what is meant by "role/permission based authorisation".

jimjimjim 11y ago

I guess it depends on the size of the project/site/page but the system of users roles and rights doesn't have to be complex and can provide a good amount of flexibility. It can be as simple as one more table in the db and a couple of lookups or a join.

keth 11y ago

Your sense of smell might be on point here. I dont know. But I've noticed that I tend to sometimes over-engineer things. Maybe because I did the exact opposite in the past and had to rewrite large parts of a hobby project because it was to tightly coupled. Took a while to answer because apparently I submit my comments too fast. :O

OrionSeven 11y ago

I tend to agree with olalonde. What you've described is a well accepted method to handle authorization (sounds like you've implemented role-based access control). But for things like, can't delete yourself, etc., those in my mind are business rules and not authorization rules. In fact that's a validation rule and not authorization rule.