I think there is a much easier solution here. JSPWiki's JAAS stack
will automatically pick up and login credentials that are populated in
the HttpServletRequest. My understanding about how ACEGI is that,
using a filter, it wraps the request with its own wrapper class and
returns the authenticated Principal via (wrapper)
ServletRequest.getUserPrincipal/getRemoteUser.
JSPWiki has always been designed to work in a scenario like this. You
shouldn't need to write a line of code. All you'd need to do is make
sure the ACEGI filter executes before JSPWiki's own.
I don't have hands-on experience with ACEGI but I think that's how to
do it.
Andrew
On Jan 22, 2008, at 7:59, Murray Altheim <[EMAIL PROTECTED]> wrote:
Simon Kitching wrote:
[...]
Thanks very much for your time Murray.
Hi Simon,
You're quite welcome.
However I am still reasonably sure that the final status of the
AuthorizationManager *is* a problem (and I have been doing this Java
thing for a few years now).
I certainly didn't mean to imply otherwise.
Let's split up the code in WikiEngine into steps:
(1) String reqClass = AuthenticationManager.class.getName();
(2) Object mgrObj = ClassUtil.getMappedObject(reqClass);
(3) m_authenticationManager = (AuthenticationManager) mgrObj;
Steps (1) and (2) are fine. Yes, it is possible to configure the
classmappings.xml file to point to my custom implementation, and
ClassUtil will happily load the Class, create an instance and
return it.
No problems here at all.
But in (3), the attempt to cast the custom object to type
com.eycrd.wiki.auth.AuthenticationManager will fail because it is
not of
that type. A ClassCastException will therefore occur and the
WikiEngine
will fail to initialise.
The solution is simply to make the custom class subclass
AuthenticationManager - but that is not possible because that class
is
final.
Yes, understood, I see your point now. It sounds like
AuthenticationManager
needs to be an API in order for this to work. Sorry to not see this
problem
earlier.
Note that I've now got a solution that works for me; I have a
custom jar
with a reimplementation of the problem classes (without final
qualifiers) and I have named the jar "_jspwiki_patch.jar", where the
leading underscore causes the servlet engine picks it up before the
real
JSPWiki.jar (alphabetical order). But sometime it might be nice to
either fix this in the jspwiki code or rip out the
ClassUtils.getMappedObject calls and just replace them with "new"..
Well, unless this is a common use case (which it might be, dunno),
it's
probably better that you have simply rewritten the 'problem'
classes. If
this is something Andrew thinks is a good idea (and he's certainly the
expert on security more than myself) then perhaps looking into
rewriting
AuthenticationManager and AuthorizationManager as interfaces might
be in
order for the future.
Cheers,
Murray
...
...
.....................................................................
Murray Altheim <murray07 at altheim.com>
=== = =
http://www.altheim.com/murray/ =
= ===
SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk =
= = =
Boundless wind and moon - the eye within eyes,
Inexhaustible heaven and earth - the light beyond light,
The willow dark, the flower bright - ten thousand houses,
Knock at any door - there's one who will respond.
-- The Blue Cliff Record
