Azure Diamond Studio

One of the projects I am overseeing is a rewrite of our in-house time-tracking application, used by employees to submit our hours, by project managers to manage budgets and track feature and defect progress, and by accounting to figure out how much to pay us.

The new application is being designed to clean up the complexity of some of the longer workflows and to be more modular and extensible. We also selected it as an opportunity to test-drive the JEE 5 collection of technologies, and are building on the JBoss AS 4.0.x and Seam stack, likely adding jBPM as well.

Without getting into too much detail, I am leary of getting too deep into proprietary JBoss extensions to JAAS to emulate support for ACLs (aka “Dynamic Roles”). And we do need ACL support for this application. So we have gone back and forth between trying to find a way to make ACEGI Security work well with JSF, Seam, and JBoss vs. just using the proprietary JBoss Security.

I’m no Spring wizard, and am relatively new to ACEGI Security, having only used them here a there in what amount to “toy” apps. I have more trust in open source frameworks than I have in particular vendor offerings, though. Unfortunately, Gavin King has become our kicking-boy in this corner of the shop lately, as he has repeatedly dismissed (would you prefer “redirected” or perhaps “deflected”) suggestions oriented towards making his new baby play well with others, and it looks like no solution to the security issue really exists yet…besides the “here, try this Kool-aid!” of cross-cutting EJB3 annotation hooks and “Dynamic Roles.” In addition, it seems there has been no progress from him in providing his own solution within Seam for simplifying ACL security issues. Maybe I just don’t understand. Very possible.

Either way, that means that developing (and contributing) our own solution becomes more likely, but finding the resources for that remains a challenge. This rewrite we are talking about is happening on the side. So here we are, in framework hell, unable to easily deploy an ACL security model into a the application, and we burn valuable resources looking for solutions. I have a fantasy of busting Seam down to provide, or at least support providing, separate filters for performing the session-related tasks of conversation management from the execution of the request, so that we can prop ACEGI Security in the middle (an execution pattern I find more attractive). Given that solution is unlikely to provide a forward-compatible solution, and particularly unlikely to be adopted given the scope of the change, we are left with trying to insert an ACEGI Security AuthenticationProvider in by crafting a SeamPhaseListener, or maybe something else.

Still hunting.

In my role as official Answer Guy for my honey’s food blog, I am accustomed to the occasional curse coming from the other room when she checks in on her blog. We regularly have gone around making small tweaks as necessary to combat the latest tactics among spammers.

1. We have installed plugins to detect spam. They helped for a few months. Her blog is just too attractive for them to stay away.
2. We changed the name of the (default) wp-comment-post.php script. Things dropped of a little but the growth of spam in general has made up for it.
3. We installed an IP-banning plugin to address some of the repeat offenders. It made us feel better but didn’t help too much.
4. We added a sentience-test to the posting process to slow the bots down. Again, things dropped of a little but the growth of spam in general has made up for it.
5. We added a nofollow tag to the comment author link url. No measurable effect, but it does reduce the temporary benefit if they do get a post through.
6. We removed the comment author link entirely. Again, no measurable effect, but we are sure that there is no benefit in them even trying anymore.
7. She started locking comments on the posts that created the largest problems. This is where it gets interesting…

We keep seeing new comments arriving on posts which have been locked. I do some digging and find each of the following:

• http://wordpress.org/support/topic/73049
• http://wordpress.org/support/topic/72930
• http://trac.wordpress.org/ticket/1848

So, curious, I go sleuthing. Ticket 1848 has never been closed. There are other holes as well. We are seeing an exploit in the wild of folks directly hitting the renamed wp-comment-post.php script (they can farm the new name easily enough), and circumventing the settings in the Discussion options. Lovely.

I’m testing the early alpha release of a plugin to patch as many of these backdoors as possible, and it will all be GPL licensed so I can nudge the WordPress committers to include my fixes directly in future releases. I want to richen it up a bit. Currently, it labels any ’sploiting comments as ’spam’ but I figure that should be configurable. I figure that while the exploit in the wild I’m seeing is not exactly like 1848 that I should add a filter step for that too, as well as investigate for other holes. I have the plugin in my private SCM right now, but have applied for space on http://dev.wp-plugins.org/ and will provide an update when I have something ready for public beta.