Ticket #60 (accepted defect)

Opened 5 years ago

Last modified 7 months ago

Include action doesn't work with case sensitive collation

Reported by: CyneBeald Owned by: JavaWoman
Priority: high Milestone: 1.4
Component: actions Version: 1.1.6.0
Severity: normal Keywords: include action case-sensitive
Cc: NilsLindenberg

Description (last modified by JavaWoman) (diff)

The Include action internally converts the requested page name into lowercase. This works on servers where the collation of the database is set to a case insensitive variant (like cp1250_general_ci), but not when using a case sensitive collation (like cp1250_czech_cs).

This might have been motivated by security concerns - preventing a circular reference, because including a page in a CI database always works, no matter the capitalization (maybe another bug?), but the implementation is a bit buggy.

I believe this can be solved by appending the real page tag to the $this->configincludes? array ( retrieved as $pagetag? after LoadPage()), instead of the parameter passed to the include action.

Change History

Changed 5 years ago by CyneBeald

  • milestone set to 1.1.6.1

I modified the code so it doesn't break on case sensitive database locales. In cases where there really is a circular reference, this code does two DB queries more than the original to find out the correct case of the included page. Since this shouldn't really happen in the normal case, I don't think that it's an issue.

<?php
if (!$page) $page = $wikka_vars;
if (!$this->config["includes"]) $this->config["includes"][] = $this->tag;

if ($this->HasAccess("read", $page)) {
        $page = $this->LoadPage($page);
        if (!in_array($page["tag"], $this->config["includes"]) && $page["tag"] != $this->tag)
        {
                $this->config["includes"][] = $page["tag"];
                print $this->Format($page["body"]);
        } else print "<span class='error'>Circular reference detected</span>";  
}
?>

Changed 5 years ago by dartar

  • milestone changed from 1.1.6.1 to 1.1.6.2

Changed 4 years ago by DarTar

  • priority changed from normal to high
  • milestone changed from 1.1.6.2 to 1.1.6.3

Patch available, moving to 1.1.6.3 and changing priority

Changed 4 years ago by NilsLindenberg

  • owner changed from unassigned to NilsLindenberg

Changed 4 years ago by NilsLindenberg

  • status changed from new to assigned

Changed 3 years ago by JavaWoman

  • cc NilsLindenberg added
  • owner changed from NilsLindenberg to JavaWoman
  • status changed from assigned to new
  • description modified (diff)

I don't see how it was ever part of the 1.1.6.3 milestone - and it it's not itself a security issue anyway - but I do think this should be fixed for 1.1.7 (for which the milestone is now set).

However doing a LoadPage just to get the 'real' page name is a bit expensive since it retrieves the whole page, so the proposed solution should be tweaked a little. Reassigning to myself, since I'm already looking at the include action and Nils seems to be busy with his studies.

Changed 3 years ago by JavaWoman

  • status changed from new to assigned
  • description modified (diff)

Changed 18 months ago by DarTar

  • milestone changed from 1.2 to 1.3

Retargeting to 1.3. Code for this ticket may have already been committed to trunk, from which 1.3 will be branched. Consider backporting urgent issues to 1.2.X

Changed 7 months ago by BrianKoontz

  • milestone changed from 1.3 to 1.4
Note: See TracTickets for help on using tickets.