I'm happy to say that Geert has accepted a batch of changes I made to
rework the authentication system so that it's much easier to substitute
user-written code to access a custom user database, use a clustered
cache for session storage, or whatever else you might want to
customize. If any brave souls are willing to give it a spin, that'd be
great -- the changes are in the latest nightly RIFE snapshot. If you are using the standard RIFE authentication elements (e.g. you have an element that extends from rife/authenticated/database.xml) then this change should be completely transparent to you; those XML files have changed a lot internally, but they still do what they did before. But if you are doing custom authentication, you can now substitute your own classes for any of RIFE's authentication-related ones without having to write your own Authenticated subclass. It used to be the case that the storage mechanisms for sessions, users, and remember-me data were hardwired into the Authenticated class hierarchy; if you wanted a user database you had to subclass DatabaseAuthenticated and so on. Now all that is decoupled from the actual authentication logic. If you crack open the element XML files such as authenticated/database.xml, you'll see a bunch of new config options that control which underlying classes are used for retrieving authentication data. Specifically:
Since a lot of the time you won't need custom instantiation logic, SimpleSessionManagerFactory and SimpleSessionValidatorFactory classes implement a simple cache of singletons based on ID/class-name pairs. If you have an implementation that doesn't need to read any configuration from the authentication element, these are appropriate to use; that will very often be the case with session validators even if you are using your own custom session manager. These factory classes expect element properties to control which classes to instantiate:
It should now be significantly easier for people to alter the behavior of the authentication system; previously if you wanted to override some piece of behavior in Authenticated, you had to subclass all the different leaf nodes of Authenticated's class hierarchy. And more importantly, if all you want to do is substitute your own user database or whatever, you no longer have to subclass Authenticated at all. Just override the credentials manager factory class in your element's configuration and you're good to go. Comments and problem reports welcome. There will be one more round of refactoring before I consider this done: the purging vs. non-purging distinction is still hardwired into the class hierarchy. See the "Refactoring Purging" thread on the devel list for some idea of what I'd like to do with that. It will, in any event, be an additional layer on top of what I've already done, so it's perfectly safe to start experimenting with the above if you like. -Steve |
_______________________________________________ Rife-users mailing list Rife-users@uwyn.com http://lists.uwyn.com/mailman/listinfo/rife-users