Rob van Maris <[EMAIL PROTECTED]> wrote: > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Michiel Meeuwissen > > > > So, therefore I made the check-code public so it can also be > > called from other Authentication implemetantions. > > > > E.g. I have changed 'cloudcontext.Authenticate' so that it > > can recognize the login method 'class' itself. It then calls > > the code from ClassAuthenticationWrapper to check the > > stacktrace and the configuration. > > I don't like the idea of the wrapped class calling the wrapper's > methods. > Why not let the wrapper handle all the authentication requests that > specify loginmethod "class", and forward all others to the wrapped > class?
That was of course the first idea, but it is impossible, because the wrapper does not know about the 'UserContext' implementation of the wrapped Authentication. Most Authentication implementions have a very specific UserContext implementation and are the only one actually knowing how to make an instance of that. Feeding a 'generic' UserContext object will generally not work, because authorization implementations nearly alway expect something specific. I don't see any other solution then that the actual Authentication implementation should itself instatiate the User object. That's why every authentication implementation should implement 'class' itself if authentication based solely on calling class must be possible. So the Wrapper takes actually two functions: - It's a utility class for Authentication implementations. - It's a wrapper to connect arbitrary (well, arbitrary, in this first simple implementation it must be Strings..) credentials to certain classes, which can be used also for name/password implementations which do not itself implement the 'class' method. Perhaps it would seem logical to split this class up in two classes corresponding to these two functions then too, but it should be noted that the 'utility' part can not work stand-alone, because the 'class' method cannot work if the implementation is not wrapped, because it would not have been configured then. So splitting up might suggest that those functions are more dividable that they actually are. Michiel -- Michiel Meeuwissen | Mediapark C101 Hilversum | +31 (0)35 6772979 | I hate computers nl_NL eo_XX en_US | mihxil' | [] () |
