Page MenuHomePhabricator

Bogus session loss message when editing a non-existent category page with $wgRawHtml enabled
Closed, ResolvedPublic

Description

Author: michael.axelrod

Description:
After $wgRawHtml is enabled The message [[MediaWiki:Session fail preview html]]
is displayed all the time when editing an non-existent category page (might be a
problem with regular pages too, can't recall at the moment) even if the session
context is fine. (Cookie is present). We have enabled $wgRawHtml for use on an
intranet Mediawiki site and having this message displayed all the time is
annoying and confuses the users.

As a work around I have simply edited the message and replaced it with a null
text string. But I suspect the bug should be addressed.

I suspect the problem might be in the code of EditPage.php around lines 513 and

Steps to recreate this bug:

  1. Log in
  2. edit a new page and add a link to a category page that has articles in the

category but no actual category page content has ever been created.

  1. click on the link to the category page.
  2. note the warning message.

I'm not so sure it is neccessary to see this warning message if the user is
logged in.

If this is not a bug then perhaps there could be some thinking done around what
to do for people in my situation. (flag to turn off the warning, document the
work around etc...)

BTW the documentation around $wgRawHtml is very weak....


Version: 1.8.x
Severity: normal

Details

Reference
bz8556

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:30 PM
bzimport set Reference to bz8556.
bzimport added a subscriber: Unknown Object (MLST).

robchur wrote:

This makes sense; when raw HTML is enabled, we do an edit token check for previews, to avoid users being taken to a page containing malicious raw HTML through innocuous preview links and the like. Of course, when editing categories for the first time, we do this preview too, but we don't bother to pass a token then.

Not sure what the best workaround for this is. We could perhaps skip the check if the text being previewed is blank.

Happened to stumble upon this today. Fixed in r90814 by not showing the warning if the text being previewed is the empty string (It still aborts the preview just to be safe, but shouldn't matter since its only the empty string being previewed).