Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3

This assumes that you want to A) do comment authentication and B) do it against an identity system apart from Roller's local db.

The Basics

In order for Roller to support comment authentication there are a couple changes that need to be made. first change is that the way the RollerSession class works to identify the authentic client and provide access to a User object representing that client needs a bit of updating and enhancing. second, we need to tidy up a few places in the code so that we use the RollerSession as the only way of getting access to the authentic client User. lastly we'll need to add some new elements to the rendering system to support dynamic comment form rendering and allow that to be tied into the existing rendering and comment posting system.

Setup Identity System

This is different for everyone so I won't go into details. The assumption though is that whatever you do to configure this works how you want and Roller can simply expect that if a client is authentic then the value of request.getUserPrinciple() is non-null.

Cleanup RollerSession

This part is relatively easy, we just need to rework and expand on the getRollerSession() and getAuthenticatedUser() methods. The primary expansion here is that we need to remove the assumption that the only place we need to look for a User is in the local Roller db, which is a very limiting assumption. Instead we want the RollerSession to consult our authentication provider as well, so that users who aren't in the local db can still be accessed by Roller via a User object.

The pseudo code for this is basically ...

Code Block
user = try local db user lookup
if(user == null) {
  user = try user lookup via authentication provider
  // CustomUserRegistry.getUserDetailsFromAuthentication();  // lookup user via Acegi
}

Make RollerSession the only way to lookup the authentic client User object

A more exhaustive look at this is necessary, but the most obvious culprit here is the ParsedRequest.getAuthenticatedUser() method, which simply goes directly to the db to look for the user. Instead this needs to be changed so that we call RollerSession.getAuthenticatedUser() in order to be consistent and of course to get the use of the new code we setup above.

The main key with this point is that we can't have different pieces of the code making up their own way of looking up the authentic client user, it needs to be the same everywhere.

Dynamic Comment Form

Now for the actual comment form rendering. The basic strategy is to do things the same way we do the comment authentication right now, which is effectively to use javascript and include that part of the page dynamically. To do this we just need a few additions to the rendering system.

  • RequestMapper - add a new url to the weblog url mapping ... /weblog/commentForm/entryAnchor
  • CommentFormServlet - For rendering just a comment form for a specific weblog entry.
  • CommentFormModel - A rendering model specifically for managing comment form data.
  • WeblogEntryCommentFormRequest - A parsed rendering request for a weblog entry comment form.
  • commentForm.vm - A velocity template for rendering the form, slightly modified from the existing one.

And to round out the implementation we need to make a few modifications to the current hook points in the rendering system which have to do with comment posting.

  • PageModel - have it pre-populate the comment form if the client is authentic.
  • CommentServlet - have it enforce comment authentication if enabled for the given weblog.

Walkthrough of how it works

  1. client makes request to weblog entry permalink page (or potentially other page using comment form)
  2. page is rendered as usual and returned to client. page includes a simple javascript call which loads the comment form in a separate request.
    1. separate request for comment form is made via javascript in clients browser.
    2. new CommentFormServlet fields the request and always renders a comment form dynamically.
    3. output of the form is dependent on template. template can require client authentication and render a simple "you are required to login to post a comment" message if the client isn't authentic, otherwise it just renders teh comment form with the client's info pre-populated.
  3. client is now looking at the fully rendered page plus comment form
  4. client fills in the rest of their comment and clicks the 'post' button
  5. comment is posted to entry permalink as usual
  6. the result of the comment posting is stored in the clients http session so that it is made available to the CommentFormServlet when the request for the comment form is made by the client's browser.
  7. at this point we simply go back to the top of the list and start over again.