Is there any way

You are the one calling the blind function right? Just do:
blind(clone $arg1, clone $arg2);

The function can modify the args all it wants but the changes will never be passed back.

That’s actually what I was doing at first, but it ends up putting three copies in memory instead of two… the original, the clone, and then the one passed…

… unless I make it so they should always be passed by reference… hey… that could work. Clone and then always pass by reference – back to the original two copies not calling by reference makes.

I like that. clone on call, & in function…

Though I tell you – some of the responses to this thread it’s no wonder most of the software out there is vulnerable as all git. If you think anything accepting client-side responses is going to be “airtight”… Wow… just… Wow…

More like house door locks… What do you do after they break the window and climb in? Shatter sensors, window sensors, motion sensors – Ever watch “It takes a thief?(particularly like the on where they break into a Police station)

It’s called layered security – same idea as a concentric castle. or the perimeter of a modern Firebase or FOB – It’s amazing how many people seem to think of site security as “all we need is the moat” – instead of a moat surrounding walls with arrow slits surrounding troops in a courtyard surrounding a keep built with layered floors for three or four more ‘layers’ heading upwards.

But then I’ve got some 2600 club kiddies as my testing group… Want to feel like a rank amateur at securing a site? Ask your local 2600 club “Hey guys, can you hack in?”

Though as the old joke goes “The only secure system is one with zero access – from there it’s just a matter of degree”

Because I’m writing a CMS end users might try to skin, so I want to sandbox the skinning system. You’ve heard of sandboxing, right? My Parser, Generator and Outputter are all sandboxed from each-other and only allowed to pass certain values between each-other. This means user input is isolated and verified before being passed to the generator, the generator is the only one allowed to have database access or to grant permission to the database, while the outputter can only receive what the others send to it and is solely concerned with handling compression, outputting headers, and writing out the markup.

Which is an impossibility when you have user input and the possibility of people adding their own modules or themes to a CMS.

Such a limited view. If I can prevent the stuff people can modify from having database access, I haven’t lost. Just because they got in the front door doesn’t mean they’re past the motion sensors… just because they’re past the motion sensors doesn’t mean they’ve broken into the safe… Just because they’ve gotten a execution exploit in place doesn’t mean they slam-bam should have access to EVERYTHING. No offense, but the “airtight” thing is the DUMBEST view on security I’ve ever heard.

Hell, the only thing I’m worried about thanks to my practices is file_get_contents… certainly not worried about anyone running code or writing to files; unless they want to try writing to a data only directory that has no execute permissions and file-handling blocked my a .htaccess. (yes, I even sandbox attachments and avatars – a lesson most forums need to learn)

Which is why PHP and/or apache shouldn’t have that level of access and why the directories and files should be 644. Again, unless you’re a #DDD running around with things set to 777, that’s a non-issue… Hell, that’s what permissions are FOR. Installed normally on a normal *nix server, chmod should bomb on ANY interpreted code file. If you’re on a server where that’s not the case, whoever set up the server needs a bullet in the head!

If all your source files and directories are

644 web4UserName|web4WebsiteName

and apache/php are running as www-data|www-data, chmod ain’t doing jack!

and if it’s a .php file you technically don’t need the execute permission for owner either, since they aren’t executables!

I guess simply saying “nothing can write to this” and having it chowned by the group/user of the account instead of where php/apache is allowed access to it is too simple and effective or something…

Bottom line – I’m just trying to sandbox code sections; one of the most basic security principles… cyclone fence with motion sensor tripped lights in the yard with internal motion sensors, and a fire-safe inside a safe-room. Beats the hell out of some fifteen year old script kiddie with a brick walking away with credit card numbers because all I relied on was window and door locks.

PHP is pretty smart about copies. Only one instance of the actual data will exist unless someone tries to update it. Only then will a copy actually be made. So don’t worry about passing by reference and stuff. Life is too short.

deathshadow60, seems like you do nothing but complain. I mean… if you don’t like the way things are done in PHP then don’t use it. Its really that simple. I don’t think anyone is holding your throat. Go use pure C or something and get as close to hardware as your heart desires… geesh. Always complaining about PHP yet your writing something in PHP, that doesn’t make any sense.

The fact of the matter is if your project is open source and I want to change something, I will. Nothing will stop anyone who knows what they are doing. So you might as well not even bother with it.

That sounds like MVC, does the parser deal with any processing?

Depends on how you define processing. In the strictest sense… no…

The MVC concept really doesn’t translate to a linear in-out script very well… and really that’s what web pages are. You send all your information and request to the server, it processes it and then sends you output…

PHP really isn’t set up for view to be able to talk directly to the controller – nor should they. Due to where the input is coming from the “controller”, input from the user, ALWAYS comes into your code first, and does not occur in realtime… so my ‘parser’ is basically the controller. User input is interpreted into something the “generator” (“model” in MVC terms) to talk to the database with and process, which is finally handed over to output for formatting and application of markup – in MVC parlance that would be the View.

Trying to do the view as the first thing and/or having the controller able to talk directly to the view doesn’t make any sense for how php works… This shows in most MVC frameworks for PHP which generally feel like ice-skating uphill to me… MVC is a great concept for a local application or realtime interaction… it’s NOT all that great an idea on a linear access interaction like a normal web page… and using it for such just ends up with that square peg and a hammer, looking for the round hole.

Best way to look at how I’m building this is:

Input -> Generator -> Output. Linear in that order, each one sandboxed from the other… to the point that my login info is purged after PDO connects (single connect), and my PDO object gets unset when the generator is done.

Though some ‘input’ does need generator to do stuff – like session handling as I’m doing my own db sessions as I want admin-rights to auto-logout after 5 minutes inactivity, while ‘joe sixpack’ users can choose to stay logged in indefinitely. (well, at least until 6 June 3052… and Dan’s no longer with us so nobody gets the joke).

the big hitch is I’m making it modular so users can add their own functionality to the generator, and to output. The trick is isolating those modules while giving them the access they need. One big step so far has been in using querystrings with prepared queries the same way many people use language strings for different languages… I then overload my pdo objects prepare/query/exec functions so that instead of taking the query you want to run as parameters, it takes the name of an array index.

	final private function prepQuery($queryName,$module,$tableName) {
		if (isset($this->queries[$module][$queryName])) {
			return str_replace(
		} else return false;

	final public function query($queryName,$module='common',$tableName='') {
		if ($query=$this->prepQuery($queryName,$module,$tableName)) {
			return parent::query($query);
		} else return false;

	final public function exec($queryName,$module='common',$tableName='') {
		if ($query=$this->prepQuery($queryName,$module,$tableName)) {
			return parent::exec($query);
		} else return false;

	final public function prepare($queryName,$module='common',$tableName='') {
		if ($query=$this->prepQuery($queryName,$module,$tableName)) {
			return parent::prepare($query);
		} else return false;

Using this approach I’m able to easily target different SQL languages by simply loading different arrays of querystrings too…