[TYPO3-dev] RealStatic HTML Files idea

[Bernhard Kraft]

Benjamin Mack wrote:

> Yes, this is a problem indeed. maybe the whole static-file-caching is
> not possible when using FE-users then. Because a cached page for every
> single fe-user doesnot make a lot of sense ;-).

In fact caching in TYPO3 is done on a "group" basis. Which means there is
a cache entry for each page which was visited by a user assigned to different
groups than others. And one for users not logged in at all.

There is a common mistake that peopel insert typoscript code like:

10 = TEXT
10.data = TSFE:fe_user|user|username
10.wrap = You are logged in as: |

and then wonder why TYPO3 shows the same username even if they logged in as somebody
else (but only when they are not logged in into the Backend - because then the page
will not be cached.

Weird not :)


> Bah, again, a nasty situation. This is a very hard one to work on.
[...]
> That's right, with the conditions you would need to keep the extension /
> module consistent with the features TypoScript offers.
>
> Another thing would be (in regarding the both approaches) -- what is the
> performance benefit of static files from your module... I'll check this
> soon.

>> To sum the problems :( in generating static pages:
>>
>> * Page expire times
>> * FE-Users
>> * Conditions

I respected all those conditions in my kb_quickfe extension.

I solved it more or less like this:

First I generate a hash value out of Page-id to display, type-val, MP (mountpoint)
vals, cHash value. from this I try to read a file corresponding to this hash value.

If the file exists it is read and unserialized - this file is small - it just contains
a timestamp when the page will expire and some additonal information. When the page is
expired the "normal" page renderin is started and kb_quickfe does nothing at all.

When the page is still valid it looks if there have been conditions set in the serialized
file. From the conditions only the condition line is stored - not the whole TS array. This
is not required because just an array is built which stores wheter each condition matches
and then a md5-sum is built out of this value - this represents somehow a hash value for the
conditions which got matched and how the match resulted.

The matching is done with a special version of t3lib_matchcondition which contains only the
most important parts - so userFunc conditions are not supported currently (I would have to load
complete TSFE and cObj)

It is then also looked at the FE-User UID which is looked up from a cookie. it is not require
to initialize the FE-User libary to look up if the user has validly logged in because there
is another cookie set which contains a clever combination of md5 values which got calculated
on the server using the ENCRYPTION_KEY variable - I am pretty sure the method at all is pretty
safe so nobody can "simulate" a login.

But currently there is a bug that somebody who logged in once can use the same Cookie to log
in forever - it times not out - I will fix this soon.

Of course when you delete a FE-User account in the BE the FE-User will only be taken access when
his cookie times out the next time (whenever it times out during normal operation he will get a new
one)

> You're writing a modified version of mod_rewrite - the apache module?
> Sounds crazy. ;-)

It is not that hard when you know quite some C ... and the apache moduel interface is also quite
easy ... the only problem are memory leaks :(


greets,
Bernhard
-- 
----------------------------------------------------------------------
"Freiheit ist immer auch die Freiheit des Andersdenkenden"
Rosa Luxemburg, 1871 - 1919
----------------------------------------------------------------------
[[ http://think-open.at | Open source company ]]