View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 2231 | Composr | core | public | 2016-02-28 07:02 | 2016-03-01 20:33 |
| Reporter | PDStig | Assigned To | Chris Graham | ||
| Priority | normal | Severity | minor | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 2231: Composr 10b2: custom page modules do not render properly | ||||
| Description | When making a custom modification of any modules found in site/pages/modules (perhaps other untested areas as well) and then saving to the site/pages/modules_custom folder, Composr does not properly render the module. ...in the case of warnings.php , it will render the form as HTML inside a string... so essentially instead of a form, you see bare HTML code. | ||||
| Steps To Reproduce | 1. Modify site/pages/modules/warnings.php and save into site/pages/modules_custom/warnings.php (you can even just save an exact copy there). 2. Attempt to load warn/punish user screen. 3. You get bare HTML instead of a form. | ||||
| Additional Information | I have confirmed it is indeed an issue with rendering custom modules and not an issue with my code. Case 1: Original warnings.php with no modifications - form works. Case 2: Original warnings.php exists, custom warnings.php also exists - form does NOT work. Case 3: Original warnings.php deleted, custom warnings.php exists in the custom folder - form does NOT work. Case 4: Original warnings.php exists, exact copy made as custom warnings.php - form does NOT work. Case 5: Customized warnings.php exists in the original modules folder; no warnings.php in custom folder - form works! | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| Time estimation (hours) | |||||
| Sponsorship open | |||||
|
|
This is the new "kid gloves" XSS security feature. It auto-escapes output components if no skills declaration is made in the override code. I'll take a look at this case and see how we can tune it to make it a bit better. |
|
|
The issue specifically here was that the fields for the form get turned from Tempcode back to a string, prior to rendering, for performance reasons (carrying through Tempcode object structure for the whole form structure, used too much RAM). This made the system not know the form fields were part of the output assembly rather than based on some kind of possible user input, so they got auto-escaped. I've now made it track the output of anything that gets internally evaluated, and know never to auto-escape that. |
