Now look at your own list. You've pointed out thrice as many cons as pros, and one of the cons is: In default config/install, easily hackable

I agree; this is a major badness. However, I said default config/install. With some hacking, you can make things much less easy to hack. Simply moving and renaming most of the config files/dirs alone adds quite a lot. Simply moving away from the default locations and names will keep most of the cracker-kiddies away.

Now, I'm not saying that YaBB is a safe system. This is by no means true. However, it's perfect for an intranet system or a limited extranet. Not every Web site has to be bullet-proof.

Summary point: YaBB is not a great system, it just appears to be one of the better ones available. It has several flaws, most of which involve how it's programmed and security. However, it's about as good as it gets right now, and a lot of its flaws can be masked and patched with a little work.

In merlyn's words, it's better to have a non-functional, secure site than a functional, insecure site.

I disagree in some cases. Philosophically, the purpose of any Web site is to function. As long as you don't house sensitive information on your site, if you get hacked, you may loose service; worse case scenario: crackers use your platform to bounce into something more vital. A non-functioning site has no value. I posit that a non-functioning site is effectively equivilent to a formerly functioning hacked-and-taken-down site.

More specifically, though, is the choice between installing a security-challenged bulletin board system or nothing at all. In the latter case, there is no added value, but your site is more secure. In the former case, the added value must be measured against the potential risk and harm from successful hacking. It's not always the case that the potential risk and harm is all that great, and it may be considerably outweighed by added value to the average end-user.

Does this mean it's OK to write sloppy Web applications? No, of course not. Always use strict, warnings, and tainting; and always code with security in mind. I would never use PHP for any major public production Web site application for this very reason, but I'm fine with using PHP in an intranet enviornment. If Amazon asked me to setup a bulletin board system, I would not use YaBB; I'd take the time and code up my own. However, for the audiences and locations my bulletin boards needed to serve, the value-add of YaBB vastly outweighed the security risk.

gryphon
code('Perl') || die;

In reply to Re: Re^2: What do people think of the YaBB forum script? by gryphon
in thread What do people think of the YaBB forum script? by kiat

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.