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
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.
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.
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.
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.
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.
