Running user PHP in Drupal
2007-03-22
Open-source CMS Drupal has a PHP mode: in addition to HTML (with or without restrictions on available tags) suitably permissioned users can put PHP in the box, enter it into the database and have it executed (eval()'d, in particular).
At first glance, this is really useful. After some more thought, although you might be tempted to throw in the odd 'echo date();', running worthwhile scripts within the environment of your CMS is going to have unnecessary overhead, even assuming you can get the two to coexist peacefully.
As regular readers may know, I'm something of a glutton for punishment, so I tried it anyway.
So far I have identified two main issues:
The first is a little mysterious: opening a MySQL connection went fine (it was to the same server that the CMS uses, but I didn't want to try and piggy-back theirs), passing it queries that included database names worked, and queries without a database name failed. So far so good.
Well, the time it took me to notice that I'd missed the database name in the latter queries was a waste, but anyway...
Rather than fix those references, I threw in the command to set the active database, taking great care to make sure I called it against the correct database connection. I saved it and refreshed, and the whole CMS fell over.
Rule 1: For some reason, Drupal cannot cope with mysql_select_db() even if you call it against a database connection it isn't using.
The second one was harder. I've got a couple of big scripts that I would like to import, so that I don't have to keep making templates and things for a uniform look: that's what the CMS is for. I'd put the PHP into the database, and it didn't do anything. I got as far as sticking in some arbitrary prints to see what was being executed, and left it.
I picked it up again a little while ago. Initially I'd been concerned that I wasn't allowed to define functions, but a quick test proved that wrong: functions were working fine. Further examination determined that I could get variables into functions as proper arguments, but not by declaring them global once inside. (Some of you may know where this is going already).
A little more research and some deep thought solved it. PHP has only two namespaces: a single global context and the context of the current function. My script was written to run in the global context, but if the CMS eval()s it within a function then the variables I declare aren't actually global.
Rule 2: Avoid the global declaration. Variables in your script root aren't global, and although you could use it to force the issue I don't recommend it. Accidentally making reference to a variable the CMS is already using could be a Very Bad ThingTM. You'll have to contrive a way of passing all necessary variables as function parameters: I recommend huge multidimensional arrays ;-)
At first glance, this is really useful. After some more thought, although you might be tempted to throw in the odd 'echo date();', running worthwhile scripts within the environment of your CMS is going to have unnecessary overhead, even assuming you can get the two to coexist peacefully.
As regular readers may know, I'm something of a glutton for punishment, so I tried it anyway.
So far I have identified two main issues:
The first is a little mysterious: opening a MySQL connection went fine (it was to the same server that the CMS uses, but I didn't want to try and piggy-back theirs), passing it queries that included database names worked, and queries without a database name failed. So far so good.
Well, the time it took me to notice that I'd missed the database name in the latter queries was a waste, but anyway...
Rather than fix those references, I threw in the command to set the active database, taking great care to make sure I called it against the correct database connection. I saved it and refreshed, and the whole CMS fell over.
Rule 1: For some reason, Drupal cannot cope with mysql_select_db() even if you call it against a database connection it isn't using.
The second one was harder. I've got a couple of big scripts that I would like to import, so that I don't have to keep making templates and things for a uniform look: that's what the CMS is for. I'd put the PHP into the database, and it didn't do anything. I got as far as sticking in some arbitrary prints to see what was being executed, and left it.
I picked it up again a little while ago. Initially I'd been concerned that I wasn't allowed to define functions, but a quick test proved that wrong: functions were working fine. Further examination determined that I could get variables into functions as proper arguments, but not by declaring them global once inside. (Some of you may know where this is going already).
A little more research and some deep thought solved it. PHP has only two namespaces: a single global context and the context of the current function. My script was written to run in the global context, but if the CMS eval()s it within a function then the variables I declare aren't actually global.
Rule 2: Avoid the global declaration. Variables in your script root aren't global, and although you could use it to force the issue I don't recommend it. Accidentally making reference to a variable the CMS is already using could be a Very Bad ThingTM. You'll have to contrive a way of passing all necessary variables as function parameters: I recommend huge multidimensional arrays ;-)
Comments