A new ZIP archive with the same files, but this time it compiles, so at least the ugliest warts have been cleaned up (not that it does anything yet!). You can just disregard the previous version.
-- Gonzalo A. Diethelm [EMAIL PROTECTED] > -----Original Message----- > From: Gonzalo A. Diethelm [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 08, 2002 09:52 AM > To: Turbine Developers List > Subject: First ideas for new security model > > > I'm attaching my first ideas on the new security model. The archive > is supposed to be expanded under org.apache.fulcrum.security. > > [Jason, I'm sending this to your personal address in case the list > doesn't like attachments]. > > These are my ideas up to now: > > * Five interfaces Permission, Role, User, Application and Session > (package entity). These have no data except for a unique String > id, and each has some basic operations related to security queries. > There are no administrative functions at this level. > > * Five classes Fulcrum{Permission,Role,User,Application,Session} > (package entity.fulcrum), that have a basic implementation of the > above interfaces. > > * Five interfaces {Permission,Role,User,Application,Session}Factory > (package factory). These define the operations to load, save and > remove their respective objects from a back-end. > > * Five classes Fulcrum{Permission,Role,User,Application,Session}Factory > (package factory.fulcrum), that have a basic (mostly comments) > implementation of the above interfaces. > > * The idea is that Fulcrum code uses ONLY the Permission, Role, User, > Application and Session interfaces, NEVER referring to a concrete > extension of them. > > * I include a sample properties file where the programmer will specify > what concrete entity and factory classes she whishes to use. > > * There is a SecurityManager class, a facade for all the factory classes > that reads the configuration file and uses the configured factories to > manipulate security objects. > > * A programmer could create new classes implementing the basic interfaces > if she wanted to have: > > a) Security objects with other information. > b) Different back-ends. > > I'm sure there are a lot of loose ends, but I really wanted to send this > to the list ASAP, for its discussion and trashing. In particular, I think > it could be useful to define more administrative functions in the factory > interfaces, trying to foresee massive operations that could be implemented > more efficiently directly by the factory. > > Best regards, > > > -- > Gonzalo A. Diethelm > [EMAIL PROTECTED] >
gonzo.zip
Description: Zip compressed data
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
