rowan.collins wrote:

(In reply to comment #0)

However, it should work if a non-protected page includes a
protected notmal template, which in turn includes a protected msghtml
template.

I don't get the purpose of the intermediate step here: if Template:bar includes
nothing but {{msghtml:foo}}, and I use {{bar}}, how is that different (and,
specifically, safer) than me just using {{msghtml:foo}} directly?

I also think doing this generically would be rather difficult, whereas the
www.wikipedia.org portal (as I understand it) already involves magic pages which
are interpretted as HTML rather than wikicode, so that special case code could
probably be extended to have a few extra levels of abstraction if necessary. :)
[But then, I *don't* know how the current setup works, so I probably shouldn't
interfere.]

apb wrote:

(In reply to comment #1)

I don't get the purpose of the intermediate step here: if Template:bar
includes nothing but {{msghtml:foo}}, and I use {{bar}}, how is that
different (and, specifically, safer) than me just using {{msghtml:foo}}
directly?

Postulate a protected page {{baz}}, which is not written in HTML, but which
would cause bad effects if treated as if it were written in HTML. Now let an
untrusted user says {{msghtml:baz}} on an unprotected page. Then the bad
effects happen. If non-protected pages were not allowed to use {{msghtml:}},
this problem would not arise.

I also think doing this generically would be rather difficult, whereas the
www.wikipedia.org portal (as I understand it) already involves magic pages
which are interpretted as HTML rather than wikicode, so that special case
code could probably be extended to have a few extra levels of abstraction
if necessary. :)

The special case code currently has exactly two levels. A "portal" page is
written in wikicode, and a "template" page is written in HTML. The HTML
template is allowed to contain a magic "$1" which means "insert HTML equivalent
of portal page here. Something in the apache config invokes extract2.php to mix
everything together.

apb wrote:

(In reply to comment #1)

I also think doing this generically would be rather difficult

If it's difficult to do generically, would it be feasible to have a few
predefined HTML templates? For example, could "Mediawiki:Search form for www.
wikipedia.org portal" be treated as a special case (via some sort of list of
special cases in the software config)? Even better, could any page that matches
the pattern "Mediawiki:HTML template/*" be treated as HTML? If so, then one
could have a protected page like "Mediawiki:HTML template/Search form for www.
wikipedia.org portal" with the right HTML code, and just say "{{Mediawiki:HTML
template/Search form for www.wikipedia.org portal}}" in the wikicode for the
portal.

Having well-known names for all HTML templates would remove the need to prohibit
non-protected pages from using HTML templates, because it would be impossible to
cause a non-HTML template to be treated as an HTML template.

Even if the list of HTML templates did not have any scope for wildcard patterns,
it would be good enough to use.

apb wrote:

How about using the extension mechanism ([[meta:
Write_your_own_MediaWiki_extension]]) to define a <rawhtml>...</
rawhtml> extension? Can an extension figure out whether it is be
ing invoked on a protected page? I imagine something like

function renderRawhtml($input) {

if ($page_is_protected) {
    return $input;
} else {
    return treat_like_nowiki_text($input);
}

}

apb wrote:

Or what if Sanitizer::removeHTMLtags() in phase3/includes/Sanitizer.php just
allowed a few extra things (like <form>, <input>, <button>) on protected pages,
perhaps under control of yet another site config option?

Or what if the definition of $wgRawHtml was changed to allow it to work on
protected pages even if $wgWhitelistEdit was false (see strip() in phase3/
includes/Parser.php)?

apb wrote:

I am still trawling the source code for ideas.

Would it work to just put some HTML code in a protected page named "Mediawiki:
searchbox", and use "{{int:searchbox}}" from any other page? The code in
Parser.php that handles MAG_INT calls wfMsgReal(), which seems to look up the
message in the mediawiki namespace and treat it as raw html. But I am not sure
whether it gets sanitised later (which would break it).

As has been explained several times, linking HTML execution to page protection is extremely unsafe.

A page's being protected does *not* mean it was written and vetted by a trusted administrator; many
protected pages are involved in edit wars for instance, and contain whatever someone left them as.
Template inclusions from there make it a huge security risk.

I'm not sure what this has to do with the magic portal page. If a special case is required, a parser extension
is my strong recommendation.

apb wrote:

(In reply to comment #7)

A page's being protected does *not* mean it was written and vetted by a
trusted administrator;

Good point. But does that also apply to text on pages in the mediawiki
namespace? (Is it possible to have a page in the mediawiki namespace that was
not written by a trusted administrator?)

a parser extension is my strong recommendation.

I'd prefer it if somebody who was familiar with the code did the work, but I am
willing to look into doing it myself. Do you have any suggestions?

Reassigned to enhancement severity, as this is a feature request.

apb wrote:

Could the new <inputbox> extension be enhanced to
support what is wanted at www.wikipedia.org?
Something like <inputbox>type=search</inputbox>,
but with more parameters (to control layout and the
presence of a language selection fiels).

Marking WONTFIX. The HTML that is already allowed in pages/templates/etc can be transcluded as needed. No additional HTML should be allowed (directly or indirectly) simply because it's been protected (per comment #7).

The www.wikipedia.org template works just fine on meta, and doesn't need this anyway.