>>>>


> On 5 Mar 00, at 1:43, Peter Thoeny wrote:
>
> > Disabling HTML in general plugs the security hole, but
> > puts some limits on the system. It depends on the
> > community if this is acceptable or not. For our internal
> > deployment of TWiki as a knowledge base for support it
> > is not.
> >
> > Any comments?
>
>
<<<<
There is only a security hole on systems that don't track who
may update a page. Anonymous sites.

When BASIC authentication is used and the logfiles can be
used to trace who edited what page then the propensity for
vicious acts is cut back a lot.

Attacks of that sort just don't happen
when all writers must identify themselves.
This eliminates the worst case.

>>>>


> >>>>
> From: "Iain Shigeoka" <iainshigeoka@yahoo.com>
>
<snip>

> From my limited experience, I think a larger danger than actual
> malicious code (ala scripts, etc) is just broken html. We will often
> get confusion when a <table> tag goes unclosed within the wiki
> text (it messes up the entire page formatting and usually results in
> a very broken document).
> <<<<
>
<<<<


In kehei we normally allow all html or XML.

This can be configured out - several users
wanted the ability to create XML and HTML example
pages easily so we added some markup toggles.
One toggle converts all < chars that are not
part of <wiki...> tags to &lt;
over a range of lines.

<wiki detag >
This makes all HTML visible.
<wiki /detag> ( or </wiki detag> )


In the case of accidently malformed or unbalanced
html the author is already motivated and
can/will usually correct it themselves if given a tool.

What they ask for is something to either check or get back in to edit.
We still allow &request=edit on most sites,
so if a save displays a badly made page it can be fixed.

One of my teammates is putting a validator in
the edit template [written in javascript] that looks
at the textbox contents while text is entered.
It really only needs to check for unbalanced <table /table>
and comment tags.

>>>>


> In addition, with stricter html parsers
> coming online (i.e. xhtml) it might be nice to be able to
> control/enforce better behaved html documents.
> ....
>
<<<<

We have 2 reasons not to make a list of "allowed" html.

One is to avoid having to chase the standard when html
version 5,6,7... comes around.
[note: do a search on my name and you see I have ties
with the W3C so this may sound funny coming from me...
lets just say its better to be de coupled. ]

The second is to make it easy for a savvy administrator
to use wiki to permit editing of other files on the site.

These "other" files are softlinked in by the admin.
The who-may-edit can come from a separate access file.

These files may contain markup that is definitely not HTML.
If the templates are kept simple then even these too
may be edited. This is also a reason not to be soo quick
to store wiki content in a database.

In some sites, kehei wiki can be used to edit the wiki templates.
Again this is secured, but very handy during the initial evolution
of a site.

this lets the motivated smarties proceed unhindered.




so it comes down to this for me:
- allow all html and limit edits to
subsets of members in your 'club'
depending on which page.

- allow limited html and unlimited edits by anyone.
graffiti walls.


;# mailto: bobr@dprc.net