Hi Steve,
I just have to thank you to have performed this refactoring. It was
one of the areas of the authentication framework that has been
bothering been for quite some time now and you just stood up and did
what was needed to fix it :-)
Many thanks!
Geert
On 24 Sep 2006, at 20:41, Steven Grimm wrote:
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:
sessionmanagerfactory_class - this is the name of a class that
implements the new SessionManagerFactory interface and creates
session managers on demand. Built-in implementations are
DatabaseSessionsFactory and SimpleSessionManagerFactory (more on
the latter below).
sessionvalidatorfactory_class - like the above, but this class
implements SessionValidatorFactory and creates session validator
instances. Built-in implementations are
DatabaseSessionValidatorFactory and SimpleSessionValidatorFactory.
remembermanagerfactory_class - as you might guess, this implements
RememberManagerFactory. One built-in implementation:
DatabaseRememberFactory.
credentialsmanagerfactory_class - and finally, this implements
CredentialsManagerFactory. Built-in implementations are
DatabaseUsersFactory and MemoryUsersFactory.
The reason we specify factory classes is that there can be
different rules for when to create instances versus using
singletons that are stored in a static cache somewhere, and to
allow factories to pass configuration to the underlying objects if
needed. For example, DatabaseSessionValidatorFactory needs to give
a Datasource to the objects it creates and keep a cache of existing
instances, whereas for memory session validation it's just a simple
"new" operation with no dependencies or caching.
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:
sessionmanager_class - implements SessionManager. Built-in
implementation is MemorySessions (there is also still
DatabaseSessions but you can't instantiate that with the simple
factory.)
sessionmanager_id - a string identifier. This means the same thing
it used to in the MemorySessions configuration, but now it can
apply to other session manager implementations too.
sessionvalidator_class - implements SessionValidator. Built-in
implementation is BasicSessionValidator, which just calls the
associated session and remember managers without any optimization.
This will be appropriate in many cases. (There is also
DatabaseSessionValidator but you can't instantiate it with the
simple factory.)
This refactoring completely gets rid of the storage-medium-based
subclasses of Authenticated. There is no more DatabaseAuthenticated
or MixedAuthenticated -- these are all just configurations of a
single class that looks at the properties. Compare rife/
authenticated/mixed.xml and rife/authenticated/database.xml to see
what I mean.
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
--
Geert Bevin
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com
_______________________________________________
Rife-users mailing list
Rife-users@uwyn.com
http://lists.uwyn.com/mailman/listinfo/rife-users
