gYaAaAaAaH!!!!

I just realized that there's an enormous security hole in bs as it is initially sketched out. Since it can run multiple sites, and since those sites are not completely sandboxed from one another, and since it relies on filesystem access, it is conceivably possible that someone with control of one site could read data from another site running in the same instance of bs. They couldn't modify it, at least, but that's not good.

Or, rather, sort of. One of the premises behind boomstick is that a site is essentially divided into content, global content metadata, functionality, site metadata/configuration, and style (which is actually a subset of the prior, but is separated out for practical reasons). Obviously we could collapse all of that into "data" (with "rules" being a subset of "data") but that's a little more ambitious than what we are tackling here. BUT I DIGRESS.

Anyway, the point is that all of these things are part of a site and tend to evolve organically, and so therefore they should have a place within the cms and should be manageable within the context of the cms. What all of this means is that essentially everything that defines a site, except for a few java libraries and whatnot, lives within a repository. There are two points of access: a web ui for updating content (because that's what makes the most sense) and subversion for everything else (because that's what makes the most sense.) This split isn't perfect -- java libs, for example, still need to be maintained globally at the cms level -- but in practice it seems pretty good. Need to change a link color to blue? Need to insert google ads into the page layout? Need to write an mp3 player/browser module? No problem -- check out a couple of directories, fire up your favorite editor, write your code, check it in, and BANG, it's versioned and deployed. (Of course, you might want to have a test site or something. Since this is managed within svn, you can branch your code and set up two sites: one with the dev code, one with the production code, both running with content from the trunk. Or the dev site can have its own dev content. Or whatever. You get the idea.) When you back up the repo, you also back up every code customization you've made. That's one of the points behind boomstick: a whole site can be (more or less) easily managed as one project.

However, I also want it to be reasonably responsive and run on relatively cheap hardware (ie, mine) and that means that, at the moment, I'm allowing it to read content from the filesystem to reduce the number of calls it's making to the svn api and to make it easier for cocoon's caching system to manage things. Which makes it more difficult to sandbox sites. ALL OF WHICH IS TO SAY that while I can have multiple sites with whomever playing around with the content through the webui, I have to trust everyone who has access to the svn side of a site. And that's a problem, because it undermines one of the principle advantages of the system.

It's not a problem at the moment, since it's principally designed for people like me, who want to have multiple sites of their own. But it will need to be fixed, in time.