Forum OpenACS Q&A: Issue with Xowiki, admins and richtext validation

We discovered recently that there is a potential issue with Xowiki as a result of the following code in template::data::validate::richtext:

# don't check, if user is side-wide admin or a package admin
        # -gustaf neumann
        if {[acs_user::site_wide_admin_p] ||
            ([ns_conn isconnected]
             && [ad_conn user_id] != 0
             && [permission::permission_p -object_id [ad_conn package_id] -privilege admin  -party_id [ad_conn user_id]])} {
          return 1
        }

what this means is that an admin can post anything he/she wants in a wiki page. Ok, that *sounds* like a good idea. Except that when non-admins try to edit the page, even just to correct a typo, they get a very confusing message telling them that their post contains illegal html. This has bitten us twice in the last month or so.

I don't have an ideal solution but would propose that we alert admins to the fact that they are submitting content that will not be editable by regular users. That would entail changing richtext validation so that it returns the proper value no matter who submitted the content (probably should be the case, anyway) and either have xowiki display a form error or display a user message along with an override variable, either in the url or in the form so that a second submit would post the content if the check fails. Thoughts?

site-wide admins can post anything they want at the wiki, which might be a good idea, but also at the forums and any other page that use a richtext widget. IMO, that's *not* a good idea at all.

Thanks for catching this. I'll remove that code from my local while a decision is made for core.

where "site-wide admins" must read "site-wide *and* package admins".
Collapse
Posted by Michael Steigman on
Yeah. I don't even think it's a good idea in the wiki. Actually, it's a pretty bad idea, as we're finding out here. Applications that need different behavior from their richtext widgets should probably be forced to write their own. The core widget should not bypass security checks.