Closed (outdated)
Project:
Skinr
Version:
7.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
20 Feb 2015 at 15:52 UTC
Updated:
20 Oct 2025 at 08:21 UTC
Jump to comment: Most recent
I'm coming here based on #2053075: prevent PHP execution by Skinr module.
There's no easy way I could find to prevent the execution of php inside of skinr*.module except to just make it impossible to enable skinr_ui, skinr_context_ui.
The ideal thing to do is make execution of php in a module depend on the php.module being enabled AND a permission inside of your module that has 'restrict access' => TRUE.
Any chance you can add that?
Comments
Comment #1
moonray commentedWhere in skinr is php allowed to be used?
Skinr context uses context module. So whatever is allowed by context is used in Skinr Context's UI. As for Skinr UI, I'm not finding anywhere PHP is allowed.
Can you provide URLs?
Comment #2
gregglesComment #3
moonray commentedThese are for import/export. This is the same as views does it (or used to do it). How was that handled in their case?
Comment #4
gregglesThe page callback for the views import form uses views_import_access which returns:
That solution is being debated in #870938: Add new permission for controlling imports where people are pushing for a dedicated permission.
Comment #5
gregglesSlight update:
1. There's a patch for views.module to make the access to the ability to execute php depend on php.module being enabled as well: #2329259: Refine import permissions / update php argument access.
2. I've committed #2053075: prevent PHP execution by Skinr module so if people are asking why skinr_*ui is disabled, that could be why ;)
Comment #6
astonvictor commentedD7 reached its EOL back in January 2025, and there is no active release for D7 for this module anymore.
Development or support is not planned for D7. All D7-related issues are marked as outdated in a bunch.