On Fri, Nov 13, 2009 at 09:08, Guillaume Nodet <gno...@gmail.com> wrote: > Yeah, it may make more sense to always return a boolean then. Wdyt ?
I think boolean makes more sense as a return, its the result of the authentication operation, "true" they are permitted, "false" they are not. If the authenticator cares about attaching more than the username to the session for downstream usage, its got the session available to do that with an Attribute. If it doesn't, it can happily ignore the whole mess and simply return its status. Returning Object is a bit sloppy, we are overloading null to mean "I hate you go away", and the return type isn't type safe. E.g. its easy to make your PasswordAuthenticator return a different type of user data than your PublicKeyAuthenticator, and downstream get surprised when one type of authentication results in an unexpected ClassCastException. The Attribute stuff on ServerSession tries to reduce the chances of that sort of runtime surprise. (Though it does nothing to ensure both authenticators actually populated the Attributes your downstream code cares about.) > Btw, I've done quite a bit of refactoring on the shell / commands > interfaces, so it will break any existing app (though the changes are > quite easy to do). Yea, I've noticed. Shouldn't take me long to update, I just haven't had the time to pick up a newer snapshot from trunk. Minor API breakages are an accepted risk for using a project still under active development. :-)
