Difference between revisions of "Issue:Magic word in titlematch is not escaped"

From FollowTheScore
Jump to: navigation, search
(Reply: line 2300)
 
Line 21: Line 21:
 
== Reply ==
 
== Reply ==
 
Macros like PAGENAME can be used anywhere within a DPL query - not ony in 'titlematch'. The problem is that the expansion happens outside DPL and DPL does not know that there once has been a call of such a macro when it parses its parameter content. Are you talking about the place where "linksto", "linksfrom", "titlematch" etc. conditions are being converted to SQL statements (~ line 1900, ~2300)? A more general approach would be to run the sanitizer before all parameters are being analysed, i.e. at the top of the parameter parsing loop ( ~ line 360 ..). But I am not sure if this would create unwanted side effects. --[[User:Gero|Gero]] 07:49, 16 February 2010 (UTC)
 
Macros like PAGENAME can be used anywhere within a DPL query - not ony in 'titlematch'. The problem is that the expansion happens outside DPL and DPL does not know that there once has been a call of such a macro when it parses its parameter content. Are you talking about the place where "linksto", "linksfrom", "titlematch" etc. conditions are being converted to SQL statements (~ line 1900, ~2300)? A more general approach would be to run the sanitizer before all parameters are being analysed, i.e. at the top of the parameter parsing loop ( ~ line 360 ..). But I am not sure if this would create unwanted side effects. --[[User:Gero|Gero]] 07:49, 16 February 2010 (UTC)
 +
:I think the sanitizer should be run for anything that can be a page title, to ensure that magic words like PAGENAME work. For some arguments (formatting?) you want to keep html codes (although you could still encode them with & amp;)
 +
:I inserted the sanitizer call here to temporarily fix this problem, starting at line 2357:
 +
<pre>
 +
        // TitleMatch ...
 +
 +
        if ( count($aTitleMatch)>0 ) {
 +
 +
            $sSqlWhere .= ' AND (';
 +
 +
            $n=0;
 +
 +
            foreach ($aTitleMatch as $link) {
 +
                $link = Sanitizer::decodeCharReferences($link);
 +
 +
                if ($n>0) $sSqlWhere .= ' OR ';
 +
 +
                if ($acceptOpenReferences) {
 +
 +
                    if ($bIgnoreCase) $sSqlWhere .= 'LOWER(pl_title)' . $sTitleMatchMode . strtolower($dbr->addQuotes($link)) ;
 +
 +
                    else $sSqlWhere .= 'pl_title'        . $sTitleMatchMode .          $dbr->addQuotes($link) ;
 +
 +
                } else {
 +
 +
                    if ($bIgnoreCase) $sSqlWhere .= 'LOWER(' . $sPageTable.'.page_title)' . $sTitleMatchMode . strtolower($dbr->addQuotes($link)) ;
 +
 +
                    else $sSqlWhere .= $sPageTable.'.page_title' . $sTitleMatchMode .  $dbr->addQuotes($link) ;
 +
 +
                }
 +
 +
                $n++;
 +
 +
            }
 +
 +
            $sSqlWhere .= ')';
 +
 +
        }
 +
</pre>
 +
 +
:And the same for notitlematch. --&nbsp;[[User:Nx|<span style="color:teal">'''''Nx'''''</span>]]&nbsp;/&nbsp;[[User talk:Nx|''talk'']] 21:20, 16 February 2010 (UTC)

Latest revision as of 23:20, 16 February 2010

Description:
Extension / Version: DPL   /   1.9.0
Type / Status: Bug   /   open

Problem

Observe: User:Nx/sand'box

The first query is correctly escaped, the second one, which uses {{PAGENAME}} is not. -- Nx / talk 12:14, 14 February 2010 (UTC)

Ok, upon further investigation, this isn't really a dpl bug. {{PAGENAME}} et al. return an escaped title: Nx/sand&#39;box -- Nx / talk 13:18, 14 February 2010 (UTC)


And the solution is to run Sanitizer:decodeCharReferences (this is what the Title:newFromText does too), e.g. in the foreach cycle:

$link = Sanitizer::decodeCharReferences($link);

-- Nx / talk 13:37, 14 February 2010 (UTC)

Reply

Macros like PAGENAME can be used anywhere within a DPL query - not ony in 'titlematch'. The problem is that the expansion happens outside DPL and DPL does not know that there once has been a call of such a macro when it parses its parameter content. Are you talking about the place where "linksto", "linksfrom", "titlematch" etc. conditions are being converted to SQL statements (~ line 1900, ~2300)? A more general approach would be to run the sanitizer before all parameters are being analysed, i.e. at the top of the parameter parsing loop ( ~ line 360 ..). But I am not sure if this would create unwanted side effects. --Gero 07:49, 16 February 2010 (UTC)

I think the sanitizer should be run for anything that can be a page title, to ensure that magic words like PAGENAME work. For some arguments (formatting?) you want to keep html codes (although you could still encode them with & amp;)
I inserted the sanitizer call here to temporarily fix this problem, starting at line 2357:
        // TitleMatch ...

        if ( count($aTitleMatch)>0 ) {

            $sSqlWhere .= ' AND (';

            $n=0;

            foreach ($aTitleMatch as $link) {
                $link = Sanitizer::decodeCharReferences($link);

                if ($n>0) $sSqlWhere .= ' OR ';

                if ($acceptOpenReferences) {

                    if ($bIgnoreCase) 	$sSqlWhere .= 'LOWER(pl_title)' . $sTitleMatchMode . strtolower($dbr->addQuotes($link)) ;

                    else				$sSqlWhere .= 'pl_title'        . $sTitleMatchMode .           $dbr->addQuotes($link) ;

                } else {

                    if ($bIgnoreCase) 	$sSqlWhere .= 'LOWER(' . $sPageTable.'.page_title)' . $sTitleMatchMode . strtolower($dbr->addQuotes($link)) ;

                    else				$sSqlWhere .= $sPageTable.'.page_title' . $sTitleMatchMode .  $dbr->addQuotes($link) ;

                }

                $n++;

            }

            $sSqlWhere .= ')'; 

        }
And the same for notitlematch. -- Nx / talk 21:20, 16 February 2010 (UTC)