Yeah, it may make more sense to always return a boolean then. Wdyt ? 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).
On Fri, Nov 13, 2009 at 16:00, Shawn Pearce <s...@google.com> wrote: > On Fri, Oct 30, 2009 at 11:27, Daniel Kahn Gillmor > <d...@fifthhorseman.net> wrote: >> >> http://mina.apache.org/sshd/configuring-security.html >> >> Also, should either authenticator do anything with the ServerSession >> object passed in? There does not seem to be any comment about that >> parameter in the interface file. > > The ServerSession parameter is there so the authenticator can attach > session attributes via setAttribute(AttributeKey<T> key). E.g. one of > my applications uses this to attach the application specific object > which represents a user and what they are permitted to access once the > session has been established. This is later then available to the > CommandFactory, and can be given to any Command implementations it > constructs. > > But if all you care about is yes-allow/no-deny, the parameter doesn't > need to be used. > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
