[TYPO3-dev] Solution strategy "cHash" tunnel WAS: tslib_patcher, pp_chashchecker

[Popy]

> > Note that this cHash request is made because teh cHash validity is not
> > checked if there's no cHash :)
>
> That has to be altered a little.

It will have no sense with this kind of tunnel ^^


1) Always check, if there is a cHash
>          <NO>
>                  send default cache
>          <YES>
> 2) Check, if cHash is valid
>          <NO>
>                   redirect to error page
>          <YES>
> 3) Check, for cache entry
>          <NO>
>                  Build page with USER and USER_INT markers.
>                     (signed parameters)
>                  Cache it. Next.
>          <YES>
> 4) Run USER_INT objects for markers in cached page.
>                     (tunneled parameters)

Wonderfull


> d) A mechanism is needed to assign the tunneled parameters to the typolink
> >> function.
>
> > I did purpose one solution : <system params (id, type, ...)>[<cached
> > params (USER)><cHash>]<uncached params (USER_INT)>
>
> That's the natural way it could look like. But it's the job of the
> typolink
> function to generate it. The format is nothing the user should directly
> bother with. Most people will translate it with coolUri anyway.

Of course it's the typolink job, that is just an idea.


>  * every params after the cHash (or all params if there's no cHash) should
> > be stored somewhere and given to USER_INTs
> Why do you want to store them? There is a server log.

Stored or re-calculated during int process is the same thing, no ?

>  * A proprety "additionalParams_int" has to be added to typolink"
>
> The API of the extended typolink function needs to be reflected carefully,
> so that it will run with the existing extensions.
>
> My first idea:
>
>   New properties
>
> * hashedParameters
> * tunneledParameters
>
>   Old property
>
> * additionalParams => depends on the setting of useCHash if it is tunneled
> or cached.

Why not :)



-- 
Popy

Vulnerant omnes, ultima necat.

http://popy.sytes.net