Introduction

[Elliot Lee <el...@lulu.com>]

Hi,

I'm a software engineer at Lulu.com. As part of the community features 
on our site, we allow users to maintain blogs there. However, the system 
that is currently implemented is very old/slow/ugly/hated. We have a 
relatively large user base, but only 6k have ever posted to their blog, 
and only 500 of those within the past thirty days. As you can tell, 
there's a lot of room for improvement, so we recently decided to start 
working on a Roller deployment to provide a new blog system for 
Lulu.com. I just wanted to introduce us and make you aware of our desire 
to work with the greater Roller community to share knowledge and effort 
where possible.

I'm attaching a preliminary "here's what we might need to do" document I 
wrote up, covering the work needed to integrate Roller into the rest of 
Lulu.com. A chat a while ago with Dave provided a lot of good insights 
on some of this stuff. Advice in any and all areas is definitely welcome.

Unfortunately I won't get the chance to be heavily involved in the 
implementation work, but my colleagues Clinton (Lulu engineering), John 
(Lulu user experience), and the rest of the community team are planning 
on making it happen. Clinton is managing the bigger-picture aspects of 
the community team as well, so he's a good person to mention things to 
like "You should base your Roller work on 4.0, because it's coming out 
tomorrow" or "You people are crazy, don't use Roller!" :)

We're looking forward to creating a great blog system and working with 
you guys. Thanks so much for the work you all have done thus far to make 
it fit our needs so well! Feel free to let me know if I can help with 
anything.

Best,
-- Elliot

Re: Introduction

[Dave <sn...@gmail.com>]

Hi Elliot,

I'm very glad to hear you're considering Roller and working with the
community to get the features you want. Comments below...


On 6/27/07, Elliot Lee <el...@lulu.com> wrote:
> I'm a software engineer at Lulu.com. As part of the community features
> on our site, we allow users to maintain blogs there. However, the system
> that is currently implemented is very old/slow/ugly/hated. We have a
> relatively large user base, but only 6k have ever posted to their blog,
> and only 500 of those within the past thirty days. As you can tell,
> there's a lot of room for improvement, so we recently decided to start
> working on a Roller deployment to provide a new blog system for
> Lulu.com. I just wanted to introduce us and make you aware of our desire
> to work with the greater Roller community to share knowledge and effort
> where possible.
>
> I'm attaching a preliminary "here's what we might need to do" document I
> wrote up, covering the work needed to integrate Roller into the rest of
> Lulu.com. A chat a while ago with Dave provided a lot of good insights
> on some of this stuff. Advice in any and all areas is definitely welcome.
>
> User DB:
>         Roller's src/org/apache/roller/business/UserManager.java class should probably be fixed up a bunch - it would be nice to pull UserData directly from Lulu, rather than having it replicated to the roller database.

What a nice coincidence. My group at Sun has the very same need. We
want Roller to be able to pull user data, roles and weblog permissions
from an external repository instead of relying solely on the
'rolleruser' and 'website' tables.


> src/org/apache/roller/ui/core/security/CustomUserRegistry.java is a relevant class in this area.
>
> Authentication:
>         We'll need to implement a new ACEGI auth provider (see acegisecurity/core/src/main/java/org/acegisecurity/providers).
>
>         Getting the Lulu cookie working properly will require some extra machinations beyond just an auth provider, since it requires interacting with HTTP requests and such. See in particular acegisecurity/core/src/main/java/org/acegisecurity/ui/rememberme and acegisecurity/core/src/main/java/org/acegisecurity/providers/rememberme. My guess is that our Lulu auth provider will only use the Lulu cookie to auth internally, and redirect people to the site login page if auth fails (with fReferer set appropriately).
>
>         One of the existing providers can be used as a template without too much trouble - my guess is that rememberme is the best place to start. I believe the authentication work can be done without a huge investment of time.

I think you can get the authentication you need via Acegi or even by
dropping back to plain old Container Managed Authentication (CMA).


> Authorization:
>         Unfortunately, parts of Acegi and Roller use a different paradigm than LPermissionManager [a proprietary authorization system in use for Lulu groups]. LPermissionManager operates under the "ask me and I'll let you know if you can do it" approach, while Acegi and Roller seem to favor the "I'll give you a list of everything you can do" approach.
>
>         There are authorization-related pieces of Acegi that Roller really doesn't use. In particular, it looks like the normal Acegi authentication provider interface includes the ability to pass back "Granted Authorities" as a result of authentication. While this paradigm doesn't work well, there is the ability to implement a more sophisticated authorization provider that better fits the Lulu LPermissionManager paradigm.

>
>         However, Roller does not currently use Acegi for authorization, making things even more difficult. On a global level, there are 'user' and 'admin' roles that each user can have. On a per-blog basis, there are 'Limited', 'Author', and 'Admin' roles that a user can have (in addition to having no role at all). The mechanism for storing & retrieving these roles is pretty much "hardwired POJOs with hibernate for persistence", but it'd be nice to find a way to abstract that a bit.
>
>         So far, I think the right thing to do might be to have Roller start using Acegi for authorization, but that type of work should really go upstream, so we should get Dave in the loop.

Part of my group's requirements is to be able to use CMA so we can
take advantage of the Directory Server, SSO and even OpenID support
that is being built into modern containers. We want an option to turn
off Acegi completely and use CMA instead, so I'm not excited about the
idea of using Acegi for either authentication or authorization. And, I
believe IBM has the same CMA requirement that we do.

Plus, I don't think either Acegi or CMA supports the authorization use
cases we now support. For example, you could setup "groups" in your
external Directory Server (or your Lulu LPermiossionsManager) as a way
to give folks permissions within blogs, but Roller needs to be able to
write to that external store when a new user is added to a blog or
persmissions are chanced. There is no standard API for doing that in
Acegi or Java EE.

What if we were to define a simple API that can be used to
store/manage user profile information, user's global roles and the
relationship between users and weblogs. Roller would include an
implementation of that API that uses the built-in Roller tables, but
you could also implement it with calls to some other system. I'm
working on a proposal for this API now and I hope to have it on the
wiki in the next week or so.


>         Something I haven't done yet is find the places in Roller & Spring that utilize the Roller roles mechanism for authorization. These would be the places we'd need to change Roller.
>
>         If we can figure out a way to get Roller delegating authorization decisions to LPermissionManager, then LPermissionManager would need to have a check added for a 'blog/post/add' operation (replacing the 'group/blog_post/add' one that is already there) and other operations as relevant.
>
> Blog creation:
>      We have the bad habit of creating a blog/storefront/etc. for users as soon as they sign up for a Lulu account. This isn't efficient, and it has added to our migration headaches for storefronts. It doesn't necessarily have to be something the user is aware of, but it might make more sense to create a Roller blog for a user when they first click on the 'my blog' link from the left nav. Doing this would also give UX the opportunity to do a "first time flow" on blogs similar to what we have on storefronts.
>
>      Group blogs can be created in a fashion similar to user blogs. Roller's blogs need to be owned by a single userid, but its authorization system gives it the ability to give multiple users access to one blog. I suggest having group blogs owned by a generic system userid, and then giving group blog access through the authorization system based on group membership.

I'm not sure I understand how it helps to have each blog owned by one user.


> Fixing up password change and user creation entry points:
>        This can hopefully be done on the UX side of things, by pointing at
> Maintenance issues:
>         Hopefully most of our code-level changes can either be contained in a separate module, or fed back
>         upstream. The main issue may be modifications to the JSP & Velocity templates, which seem a lot
>         harder to modularize.

Yes, you are undoubtedly going to have some customizations. Take a
look at build.xml and the custom directory. It's possible to add your
own classes and files to the Roller build by adding them to that
directory and setting up the xmlf files there.

- Dave