Ticket #13572 (confirmed Bug)
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
Note: See
TracTickets for help on using
tickets.