Need help with encode_php_tags data in database.

[eluser]Ergose[/eluser]
Here's my scenario, because I'm stumped and is my first time actually trying this.

I have a controller that needs to pull some data from the database. The data in question is PHP code that was entered using the encode_php_tags with an update form. I am trying to retrieve and execute the code from the database.

So the questions...
If I'm going to be executing the code should I not use encode_php_tags in the first place?
If not and I wanted to also display the code in a view later would I run into possible problems that I may not be forseeing?
Is there a function I can call in the controller that can convert it back so I can parse it if needed(easiest fix at this point in the project.)?
I'm assuming I'm just running exec($the_php_data) on what comes back, might I be missing something here?


Thanks in advance,
Ergose

[eluser]Ergose[/eluser]
Heh, oops, as for the last question I just realized I should be using eval() for that, but I'm assuming the same questions above will still apply.

[eluser]Ergose[/eluser]
Yup, just checked, the above questions still stand, but eval did try to parse and ofcourse got hung up in the converted characters in the PHP tag as expected.

[eluser]Ergose[/eluser]
Ew... kinda cool, but kinda not. eval() does not like the "<?php", "?>" tags, it just wants commands, which does work for now in this scenario. However, it looks like if I have them in, I will have to use regex or something to strip out the tags when being eval()ed, but when displaying source code on a page, I could just display raw what was stored in the DB with no probs.

Ok, going for a coffee, aside from my questions, I'm pretty much finished on this controller.
I'll check back soon.

Thanks again in advance to anyone willing to put in their two cents.

[eluser]Derek Jones[/eluser]
Well I'm going to base my response on the broaaaaad assumption that this is trusted data. You could just circumvent the need to replace it by forcing a closing tag first.

Code:

eval('?>'.$row['php_code']);

[eluser]Ergose[/eluser]
hmm, I'll have to try that, but I think I'm missing something.
What is in the DB that I was toying with(and this is off the top of my head right now) is:

Code:

[encoded "<" from where I used encode_php_tags]?php echo 'test'; ?[encoded tag ">"]
&lt;?php echo 'test'; ?&gt; in the DB threw a different error because the tags were in there.
echo 'test'; in the DB works.

So given those tests, would eval('?>' . $row['php_code']); somehow make eval convert the tags, or am I missing something, because I don't figure it would.

Just to clearify as I had alot going on earlier. I would like to store the PHP code in the DB and be able to execute it or display the source or edit it when I have everything locked down later. So, being that I get forgetful in a hurry, I figure being able to have the tags in the DB and rip them out via regex or something would be better, even though it would be a little extra work. Then if I put in the PHP with or without the tags, by the time it gets eval()ed, eval would be happy.

As for the trusted data part, I am being really anal on it. I and I alone will have access to that part and I'm splitting that part of the interface off, on it's own, on a separate server, under totally different credentials and permissions. It's mainly there to aid me in my development efforts. I've been working on a site rendering system, with a multisite management backend, and preferably a development backend to aid me if I need to make quick additions to the site that need to be more dynamic, but the last takes lowest priority. In this case, however, I may as well have made the fields in the DB and was testing parts that would use this later, so instead of going back and having to debug these modules all over again, I figured I'd kill two birds with one stone. Plus, as usual, I'm having to balance security with functionality because super secure is great, but it tends to not aid in production all the time. I unfortunately am not in a possition to lead a team that could have someone dedicated to just looking for security probs, nor are there the resources.

Anyway, calling it a night.
Ergose signing off...

[eluser]Derek Jones[/eluser]
I'd personally leave it in the database unmodified, and worry about converting the characters on display. It's best practice to treat the database just as you would any input, and anytime you send it to the screen, you should have a short list of appropriate preparations for the consideration and intent of the data.

[eluser]Ergose[/eluser]
Thanks for the second opinion Derek, I agree that most of the time database should be raw storage for raw data in a sense. In this scenario, after mulling it over the course of the night, I think a middle ground might work here.

On the input form I'll just dump it in without the tags, but if tags are put in, then remove before submittal(making removal of the tags part of the "validation" step in essence).
In the controller, I could then just eval() what was in the database directly.
If I ever need to view with the tags, I can just pop them back in on the display.

The only problem I foresee would be if I wanted to dump the PHP in the DB individually into a file with the tags, but that will probably never be done as I'll be backing up the DB regularly in it's entirety per site, and there's no need to do them individually with the tags in a file because of how it's being used.

Also, I am assuming at the moment that encode_php_tags only does the tags, if anything else I may have to fall back to your opinion. I figure why not give it a crack though.

I'd say this one's closed. Thanks again for the input/help.

Ergose