On May 1, 2009, at 3:30 PM, Andrew Zeneski wrote:
Don't worry, I expected some level of resistance to a change of this
magnitude, plus this requires a very different way of thinking so I
planned on having to explain it, I tried to cover everything in the
document, but that's impossible to do :)
Yes, I agree... a discussion and feedback is a far better approach.
This is VERY similar to the existing security implementation, and
very similar to other security APIs out there (JSecurity, Spring
Security, etc). The slight differences are:
Easier to understand and follow. Reading the new permission string
format, you can see what is being checked. Nothing is hidden. The
logic used to determine granular access control it defined on the
permission itself. No more guessing where permission logic is located.
Subjective benefit.
It is much easier to extend, create seed data which overwrites the
default permission logic references and use your own custom logic to
determine access. No need to override service definitions or patch
code (well once the migration is complete) or comment out ECAs.
Also a subjective benefit.
-David
