Matthew Nuzum wrote: > - First time a person goes to http://<SITENAME>/bboard a folder is created > in site-root that contains the images, database files, header.html, > footer.html (should we allow php here?) and a simple config file. > - Config file is plain text, VARIABLE:VALUE type file. No PHP, so there can > be no malicious code or looking at other people's database. Default values > will provide a fully functional board, but changing them will allow better > integration with the site. > - A username/password is specified in the config file that allows moderation > of posts.
So anyone will end up creating a board just by going there? Even an end-user wandering around? I'm not sure this is a good idea. The actual setup on a per-site basis needs to be controllable; this is a major fault of the Cobalt-specific installation of neomail. We get around it by not telling anyone, but I really don't think that's as much protection from setting it up on sites we haven't sold it for as I'd like to see. > So here are my specific concerns: > What do you think of the virtual URL, http://<sitename>/bboard? Any > concerns or suggestions? That's fine. > What do you think of the idea of creating a folder in the site root called > /bboard that contains files that can be customized? I thought it would be > nice to put the database files in there so that they can use up the site's > storage space. The alternative is to store all database files in a central > place. Actually, as I write this, I may have difficulty creating a folder > in the site root, due to permissions. The webserver doesn't have write > permission on the site-root, does it? The biggest problem I have with site-root (as you call it) is that it won't get automatically moved with CMU. How about putting it inside of <web> with permissions and ownership that'll keep it from being readable by end-users. For example, putting an empty index.html file into it keeps people from seeing it's contents. > What do you think of the ability to allow PHP code in the header and footer > of the page? Probably a bad idea isn't it? Maybe a config option can be > put in that allows that feature to be selected. Some server admins may want > it, others may not. That's probably the way to do it, and by default, have > it turned off. KISS. Keep it supremely simple <smile>. If you're not using PHP for the board, I'd not allow it inside the board. I'm installing ubb for a client now; they sell for $300 and they don't have any PHP ability, so why do you need it <smile>? > Any other concerns or gotchas to suggest? If this were ready I'd be looking at it today, for my own use, and for clients. When <smile>??? Jeff -- Jeff Lasman <[EMAIL PROTECTED]> Linux and Cobalt/Sun/RaQ Consulting nobaloney.net P. O. Box 52672, Riverside, CA 92517 voice: (909) 778-9980 * fax: (702) 548-9484 _______________________________________________ cobalt-developers mailing list [EMAIL PROTECTED] http://list.cobalt.com/mailman/listinfo/cobalt-developers
