Full Page Cache - please do not use this feature

[datakick]

Hello everyone,

I just wanted to advice anyone who is using Full Page Cache to turn this feature off. I just found very serious security bug in the code.

Nobody should use this feature until it's resolved.

Edit: There were many bug fixes in thirtybees 1.0.7. The security bug was fixed as well, but the whole functionality is still NOT usable

[the.rampage.rado]

Great work @datakick !

Looking forward to 1.0.7 when hopefully it will be included.

I don't use it at all, too bugy and I literally don't have time to tweak and find what's causing my issues.

[suzaanroshan]

Thank you for your information

[dosbiner]

okay, will turn off now till resolved, nice catch ;)

[datakick]

tl;dr : Full Page Cache should still not be used at the moment

Update regarding Full Page Cache in thirtybees 1.0.7

Thirtybees 1.0.7 version contains couple of fixes to FPC that tries to solve most of the problems described here, including quite serious security bug.

Unfortunately it seems that there is another issue that makes this functionality unusable.

What is FPC, anyway

The theory behind FPC is really quite simple. Thirtybees will save rendered page into the cache, and any subsequent request to the same url will be served cached version. There is also a mechanism that removes entries from the cache when related database entities changes. So, for example, when product gets updated, all cache pages related to this product be removed from cache.

This works nicely, as long as there aren't any modules that hooks to the page. We can't just simply cache html content generated by module. We don't know what that content is, and what event should trigger removing this content from cache.

As an example, imagine review module. Such module will have some hook to display review list on product page. Now, what happens when we create new review, and the FPC is enabled? This new review will NOT be displayed on product page, because thirtybees does not know that it should flush cache when there is a new review. It only knows to flush cache when the product itself changes.

On the other hand, there are many modules that generates content that is safe to cache, because this content depends only on related entity (product). For example, module that changes color picker.

This is the reason why FPC allows you to choose hooks which content should be cached, and which not.

In older ( <= 1.0.6 ) versions of thirtybees, all hooks were cached by default, and merchants could only decide which hooks should NOT be cached. This opt-out principe was really a bold decision, and it caused many modules not to work by default (reviews module, nocaptcharecaptcha, newsletter, etc...)

So, for 1.0.7, we decided to change this to opt-in -- hooks content are not cached by default, and merchants need to decide which one to cache. This should make the whole system more reliable.

The bug

Unfortunately, the mechanism that dynamically evaluates the hook and injects the fresh content to cached page contains a bug. And it's a nasty one, one that can acause 500 error code on some pages.

This bug was always in the code, it just didn't manifest so often, because all hooks were cached by default. You could reproduce the same error even in 1.0.6 code, if you toggled the hook from cached to non-cached state.

It's possible to get rid of these 500 error codes even in 1.0.7 simply by making all hooks cacheable (toggle them to green). But then many modules will stop working correctly.

Conclusion

At the moment, the FPC is not usable. Not until we fix this newly discovered bug

[wakabayashi]

@datakick I am still very confused about red and green? Did you change this mechanics? I am on 1.0.3 and there green means: always load the hook without cache!

[datakick]

@wakabayashi said in Full Page Cache - please do not use this feature:

@datakick I am still very confused about red and green? Did you change this mechanics? I am on 1.0.3 and there green means: always load the hook without cache!

In 1.0.7, as a result of changing behavior from opt-out to opt in, the colors are inverted. Red color now means slow (non-cached) hook, green means fast / cached hook. I believe this is what everyone would expect, anyway.

You are right, in previous versions the colors were inverted, the green meant slow and red was fast. Weird

[saraesfehani]

thanks

[rubben1985]

@datakick Really???? I always thought it was the opposite. I now understand why cache created me problems even if all the options were deactivated..... because indeed all were activated...

[wakabayashi]

@datakick said in Full Page Cache - please do not use this feature:

@wakabayashi said in Full Page Cache - please do not use this feature:

@datakick I am still very confused about red and green? Did you change this mechanics? I am on 1.0.3 and there green means: always load the hook without cache!

In 1.0.7, as a result of changing behavior from opt-out to opt in, the colors are inverted. Red color now means slow (non-cached) hook, green means fast / cached hook. I believe this is what everyone would expect, anyway.

You are right, in previous versions the colors were inverted, the green meant slow and red was fast. Weird

Thanks a lot for the clarification @datakick! I agree, that the new system is much better, as the old one confused 90% of the users!

[sungirl]

@datakick This is great and perfect Thank you for sharing