CookieMonster
by THOMAS, BRIAN M (ATTSI)
I apologize for the length of this message, but it's a topic that I
believe to be of pretty wide interest and takes some explaining.
I've built a servlet filter to intercept requests and demand cookies,
redirecting to an enterprise SSO server if they're missing or invalid.
Intended to provide the benefits of the SSO server to any J2EE-compliant
servlet, it implements the servlet API methods
HttpServletRequest.getUserPrincipal() and
HttpServletRequest.isUserInRole() in a custom HttpServletRequestWrapper,
which it initializes with the cookie-supplied information and then
passes down the filter chain. An interface for writing custom adaptor
classes is provided, and for XWiki I use it to customize the Principal
to prepend "XWiki." to the value to be returned from
Principal.getName(). All this is working splendidly for XWiki without
the need for any custom versions of the authentication, rights, or group
services, which was a design goal.
Another design goal was to eliminate the need for manual registration of
new users, either by themselves or administrators, by automatically
registering any user not already registered before passing the request
on. My filter provides two possible avenues for this: first, a second
filter, which can be placed after the first, sends a generic POST
request with all the cookie data to a custom-crafted URL, which is easy
enough for an application such as XWiki to provide - or so it seems;
second, adding code (in the application-specific adaptor interface
mentioned above) to accomplish the task directly using the XWiki APIs.
The first approach would have required a custom form, and it looked hard
enough that I didn't try it, but most of all I couldn't work out how to
get the correct permissions. Between that and the second, I created a
URL object with which I formatted a GET request to the
XWiki.RegisterNewUser page. That had significant problems, chief of
which was determining whether the registration had actually worked - the
HTTP status doesn't tell you, and I'd have to parse the response to
guess the answer. Changing the form (which I had to do anyway) would
make that easier, but I didn't like that answer either.
So now I come to the second approach, which has so far been the most
straightforward and appears, sometimes, to work, sort of. There is an
XWiki.createUser() method that takes only the user name, a Map of object
properties, the parent document name, the user profile document content,
the user's privileges and the XWikiContext. All of those except the
XWikiContext can be determined easily, but what goes into the context,
and how it gets there, is another question, not to mention how I get my
hands on the XWiki object running in the servlet to exercise that
method.
The second problem was attacked first. I found that after the servlet
had handled its first request after starting, there was a property in
the servlet context called "xwiki", and the currently running instance
was its value. Bingo. As long as I could be sure I wasn't the first
customer of the day, everything was great. And that would still work if
it had to, but I still didn't like it. Putting a breakpoint in
XWiki.init_xwiki(), which looked to be where the show began, showed me
that it was called by a chain of (deprecated) constructors called,
ultimately, by static method getXwiki. Now we're getting somewhere.
But still I had to get some information into the XWikiContext which I
had to pass to that method.
I've had a bit of trouble getting to the method in the Struts packages
that is called to initialize the context, and I'll probably find it
eventually, but it's taking a long time and I'm hoping that someone has
better understanding of Struts and J2EE and other such stuff and could
shortcut my current route to understanding all of this, and/or to
suggest a better approach.
So, in short:
1) Where, if anywhere, can I jump into the XWiki APIs to initialize
the context properly? and/or
2) If this is a stupid way to approach the problem, what would be a
wiser one?
Thanks in advance, as always,
brain[sic]
