[TYPO3-ect] tx_base - tslib_pibase modernized

Michael Stucki michael at typo3.org
Tue Apr 3 13:57:58 CEST 2007


Hi Elmar,

>> I mean the extension might not care about it, but if you set
>> "pi_checkCHash" to TRUE it is TYPO3 who will check if the cHash is
>> correct. As soon as you set the pageNotFoundOnCHashError to 1 and your
>> USER_INT starts using piVars in _GET, you will get TYPO3 errors
>> ("Request parameters could not be validated").
> 
> I am aware of this problem. Without the pageNotFoundOnCHashErr cache
> handling is easier to understand than with pageNotFoundOnCHashErr=1,
> because we could set pi_checkCHash always to on and the extension
> developer has not to care about it anymore.

Let's say this: Usually a cached object is a USER object and has
$this->pi_checkCHash set to TRUE, while for non-cached objects (USER_INT) it
is the opposite. I'm aware that it's currently possible to do this
differently, but practically I see no sense in it. For me it seems ok to
require that cached objects require cHashes all the time.

So maybe we could just set $this->pi_checkCHash and $this->pi_USER_INT_obj
automatically, like this:

=== cut "pi/class.tx_myext_pi1.php" ===
class ... {

        function main() {
                if ($this_is_a_user_obj) {
                        $this->pi_checkCHash = TRUE;
                        $this->pi_USER_INT_obj = FALSE;
                } else {
                        $this->pi_checkCHash = FALSE;
                        $this->pi_USER_INT_obj = TRUE;
                }
        }
}
=== cut "pi/class.tx_myext_pi1.php" ===

> Maybe it's a kind of conceptional bug in the core. The current fix
> of this bug is to ser pageNotFoundOnCHashErr=0. Wouldn't it be possible to
> alter the pageNotFoundOnCHashError behaviour by an additional condition:
> 
> *******************************************************************
> Onlycheck the cHash if a cHash has been given.
> *******************************************************************
> 
> That would IMHO solve the problem.

This would work with USER_INT objects, but still I dislike the solution
because this way you can just remove the cHash from a URL and send whatever
you want to that page. I would rather like to enforce the cHash to me it is
not only a "cacheHash" but also a "checkHash". One day I would like to use
it for solving the "&no_cache=1" problem...

Why not move the declaration of cached/non-cached object into extTables.php
like this:

=== cut "extTables.php" ===
$cacheMyExtension = t3lib_div::_GET('tx_myext_pi1[no_cache]) ? FALSE : TRUE;
if ($cacheMyExtension)  {
                // Add this plugin as a USER object
        t3lib_extMgm::addPItoST43($_EXTKEY,'pi1/class.tx_myext_pi1.php','_pi1','list_type',1);
} else {
                // Add this plugin as a USER_INT object
        t3lib_extMgm::addPItoST43($_EXTKEY,'pi1/class.tx_myext_pi1.php','_pi1','list_type',0);
}
=== cut "extTables.php" ===

Combining this with the code from above, this would cause
$this->pi_checkCHash and $this->pi_USER_INT_obj of this plugin to be set
correctly and automatically, simply depending on the existance of a
new parameter in the URL (which can still be part of the cHash, btw.).

- michael

PS: $TYPO3_CONF_VARs[FE][pageNotFoundOnCHashError] can be changed back to
    TRUE by default again for this (just for 4.2 and later, of course).
-- 
Use a newsreader! Check out
http://typo3.org/community/mailing-lists/use-a-news-reader/


More information about the TYPO3-team-extension-coordination mailing list