I have been thinking a little more about Turbine's current security service and the model behind it. I believe things could be simplified by refactoring things into the following ideas:
* Very shallow interfaces for User, Permission, Role, Application and Session. These only hold a unique key for each object and have methods to query and set their relationships; for instance, Role would have getPermissionSet, hasPermission, addPermission, removePermission, etc. And maybe some administrative methods for each, such as rename, delete, etc. Of course, User would have validatePassword and changePassword, and would hold a Session. * A straightforward implementation for each of these interfaces within Fulcrum: FulcrumUser, FulcrumPermission, etc. * ALL USES of the security objects in Fulcrum and Turbine must be through the security interfaces! If we find that there are additional fields required to keep Turbine's current functionality (I believe last_access could be one of these), we could discuss adding those to the basic interfaces. (Notice that up to this point there is no information on how these objects are loaded, saved, etc.). * Interfaces for mapper objects that take care of loading, saving, etc. the basic security objects from whatever backend. For example, UserMapper would have load, save, rename, delete, etc. This opens up the possibilities to map the security objects to whatever backend the programmer wants to use. * A straightforward implementation for each mapper within Fulcrum. This implementation could just read the data from an XML file and forbid any modification of the data; this way, Fulcrum would not require a DB for its basic configuration. * A good set of configuration entries in TR.props, so that the programmer can choose what classes to use for each of the security objects and each of the mapper objects. * Turbine 3 could include objects such as ClassicUser, etc. that extend FulcrumUser, etc. and add all the other data fields that are there today (email, etc.). This could or could not be the default security implementation within Turbine; that's not for me to decide, although I do believe it should really be simpler than it is today. Advantages: * We could still support Turbine's current security service. * We can get rid in the default implementation of all those awkward data fields (email, etc.). * We can support multiple backends for security data (XML, DB, LDAP, NT security, whatever). * Whatever Turbine uses to implement its default security service (say, based on XML and read-only, or based on a DB with today's fields), a programmer can "extend" this implementation by writing her own classes for security and mapper objects. I believe this could be implemented pretty easily, but would like to get some feedback before starting the work. Regards, -- Gonzalo A. Diethelm [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
