Ticket #13572 (confirmed Bug)

Opened 3 years ago

Last modified 3 years ago

five.customerize: bad class caching

Reported by: dieter Owned by:
Priority: minor Milestone: 4.x
Component: Backend (Python) Version: 4.2
Keywords: Cc: dieter@…

Description

five.customerize==1.0.3 is not careful with respect to class caching in its module zpt. At various places, it uses code of the form:

        if self.view is not None:
            return self.view
        view_class = self.template.view
        if view_class is not None:
            # Filesystem-based view templates are trusted code and
            # have unrestricted access to the view class.  We simulate
            # that for TTW templates (which are trusted code) by
            # creating a subclass with unrestricted access to all
            # subobjects.
            if hasattr(view_class, '_five_customerize_ttw_class'):
                TTWView = view_class._five_customerize_ttw_class
            else:
                class TTWView(view_class):
                    __allow_access_to_unprotected_subobjects__ = 1
                view_class._five_customerize_ttw_class = TTWView
            self.view = TTWView(self.context, self.request)
            return self.view

This means it computes a new class TTWView from a given class view_class and caches it on the original class. Unfortuntely, it fails to take care of inheritance. If a class has been computed for a base class, this is (wrongly) used also used for a derived class.

To fix this problem, if hasattr(view_class, '_five_customerize_ttw_class'): should be replaced by if '_five_customerize_ttw_class' in view_class.__dict__ (whereever it is used in five.customerize.zpt).

Change History

comment:1 Changed 3 years ago by dieter

  • Cc dieter@… added
  • Component changed from Unknown to Backend (Python)

comment:2 Changed 3 years ago by kleist

  • Status changed from new to confirmed
Note: See TracTickets for help on using tickets.