"rememberMe" (logon) requires someone to store, load and remove the username and password. Usually that is via a Cookie or two but everybody preferrs a slightly different approach. Store and load might be implemented in SignInPanel, SignOut however is via Session.invalidate() and it would be bad pratice to reference the signInPanel instance within the session. Whilst implementing all three (load, save, remove) in SignPanel is awkward, same is true for implementing them all in a Session subclass. So I decided to implement a IAuthenticationStrategy, very similar to IAuthorizationStrategy and provide a default implementation available via ISecuritySettings. Load and save can easily make use of it, only remove still requires to subclass WebSession. Calling MySession.signIn() and MySession.isSignedIn() from within SignInPanel is yet awkward as well. All that though signIn and isSignedIn is required by 99.5% of all applications. So I implemented it in WebSession. signIn() itself calls WebSession.authenticate() which is the only method to be implemented by your applications. Usually I would make authenticate abstract but that would require really every application to implement its own MySession. Not sure this is a good idea, which is why my current implement throws an exception to remind the developer to subclass and replace it. Another option would be to delegate to an abstract Application.authenticate(). What do you think? What would be your preferred option?
Juergen
