4 ms·
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
by 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 agoOthers 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 agoWhat 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 agoOk. 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".