I feel that per-field security is too bothersome and impractical.
My opinion is that per-screen security should work ok in most cases and this
is bes accomplished by implementing security in a screen class and then
inheriting from it.
Fedor.
On Wednesday 16 May 2001 19:31, you wrote:
> I've been looking at Turbine security, and had some ideas I wanted to
> share.
>
> The page at <http://jakarta.apache.org/turbine/howto/security-howto.html>
> tells me I should write a bunch of if statements in my screens and actions
> to allow or deny select, insert, update, and delete access to application
> data. I think that it wouldn't be hard to make the data security more
> data-driven, rather than application-driven. This would allow you to
> specify access at design time, rather than coding time, and possibly
> automate the access control generation (a la torque).
>
> I've been tinkering to see how this could be implemented, and I've come up
> with the following so far:
>
> - Create a table called "TURBINE_ACCESS_CONTROL" with columns
> GROUP, ROLE, RELATION, FIELD, and TEST (explained below).
>
> - Add a "DataManager" interface, analogous to the "UserManager"
> interface, with all its associated classes. (I figure this
> should be pluggable in case you want to manage data access from
> an LDAP server. Is that reasonable? I don't know much about LDAP.)
>
> - Add methods to org.apache.turbine.util.security.AccessControlList to see
> if a user has access to particular relations (tables) and fields
> (columns)
>
> - Add grant/revoke methods to the SecurityService interface, and
> all the associated classes (BaseSecurity, TurbineSecurity, DBSecurity,
> etc.)
>
> - Create interfaces AccessControlledRelation and AccessControlledField
> so the SecurityService can call back to the peers at run time to
> determine access dynamically (e.g., if the logged-in user created the row
> in question, then he can delete it). This would be used in case the TEST
> column in TURBINE_ACCESS_CONTROL were non-null.
>
> I've posted a diff at <http://dawnstar.org/diff.txt>. See also Field.java
> and Relation.java in the same directory. The diffs almost certainly do
> not compile, and half is still crap, but it may clarify some of what
> I'm talking about.
>
> I should also note that this scheme can peacefully coexist with the
> current scheme. There's nothing to stop anyone from using permissions.
>
> Let me know what you think, I'd appreciate any input.
>
> cheers,
>
> -- Travis Low
> <mailto:[EMAIL PROTECTED]>
> <http://dawnstar.org/travis>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
