Geoffrey Young’s profile

resistance is futile

Posted in Luke Welling Joins OmniTI.

Sat, 14 Apr 2007 at 00:31:05 GMT

yeah, it's pretty exciting what has been going on recently through a series of private emails - lots of interest in all the frameworks we covered, both in making themselves better and in creating TAP output formats.

as for Ken's talk, I find it very ironic that he mentions TAP by name but suggests that no work has been done in joining perl and php. especially since it wasn't called TAP until you decided "ok 1" needed a better name for our "Testing PHP with Perl" talk at ApacheCon2004 :)

Posted in Power PHP Testing.

Mon, 19 Dec 2005 at 18:11:07 GMT

simple-test's tap reporter has lots of potential, but I think to make it truly awesome it ought to mirror the output of Test::More just like test-more.php does.

really, nobody would be using the tap reporter outside of Test::Harness, so going the extra mile to match that output format (odd spacing and all) would have lots of extra benefits, especially in Apache-Test - users could seamlessly switch between Test::More in t/foo.t and test-more.php or tap reporter in t/foo.php or t/response/TestBar/foo.php and the output would be identical! really, that would be a huge win (besides the fact that Test::More and clones have far better diagnostic output than anything else).

but maybe such verbose output, like the line number of the error, and expected and received values, aren't possible because you're limited by what simple-test provides to the reporter? hmm...

Posted in JApacheCon.

Thu, 15 Dec 2005 at 15:24:21 GMT

nice code syntax highlighting :)

Posted in PHP Security Audit HOWTO.

Tue, 14 Jun 2005 at 01:31:09 GMT

wrt oop, that's part of the beauty of Apache-Test - it sets everything up and lets you choose the testing library. so, if you like oo use a Simple Test-type syntax. if you like procedural tests, use the included test-more.php. or use test-more.php for oo if you like (I do all the time over in perl land). or write your own TAP-compliant library.

none of this matters to Apache-Test, which is just in charge of configuring up apache, starting the server, running your tests, and aggregating the results, and stopping the server in preparation for another run.

Posted in Apache-Test and SimpleTest.

Fri, 25 Mar 2005 at 01:03:33 GMT

it seems like a good match. really, what Apache-Test provides is a framework to build upon - that we added test-more.php was really just a way to give php folks an easy way to use the infrastructure. Simple Test looks to provide lots that is valuable when writing tests, such as mock objects, so joining the two ought to be pretty powerful.

Posted in Apache-Test and SimpleTest.

Mon, 21 Mar 2005 at 15:20:37 GMT

wahoo!

Posted in Brain Bulb, The PHP Consultancy.

Fri, 18 Mar 2005 at 14:38:53 GMT

I know it's not foolproof, but legitimate businesses could help inform users a bit better just through some interface changes. for example, if you visit http://www.apache.com/en/ad_software.php and click on the "download apache" button on the right you are redirected not to where the page wanted you to go (check out the desination URL before you click), but to a site saying where you've been.

it can't be that difficult to trap landings from non-official sites - the apache.com trap is just a RewriteCond/RewriteRule pair.

Posted in Phishing.

Fri, 18 Feb 2005 at 02:50:35 GMT

:)

Posted in More on Filtering Input and Escaping Output.

Wed, 09 Feb 2005 at 23:01:07 GMT

well, because they are in $_SERVER don't they come from the server by definition?

;)

so long as we're talking about apache and not some other php variant, these are each created via calls to apache's special APIs, ap_add_cgi_vars() and ap_add_common_vars(), which actually put these values into the execution environment. so anyone who can intercept the root of these values before those APIs are called can cause your data to be tainted...

1. $_SERVER['DOCUMENT_ROOT'] - this is taken straight from the private DocumentRoot httpd.conf configuration variable (so long as someone like mod_perl hasn't altered it before PHP took a peek at it).

2. $_SERVER['HTTP_HOST'] - ok this, like many others, is taken straight from the incoming request headers. in the case of host, it doesn't even need to be correct - you can use an absolute URI for the request and mungle the Host header and things will probably still work. not the best thing to trust, in any case.

3. $_SERVER['REQUEST_URI'] - this is taken directly from the GET request line, so I guess that makes it originate from the client. however, apache will validate this somewhat (for instance apache 1.3 will immediately fail if the URI that doesn't start with a slash). of course, mod_perl can muck with this value too, as can any number of input filters in httpd-2.0.

4. $_SERVER['SCRIPT_NAME'] - this is calculated by the server based on the requested URI, so again it's _kinda_ coming from the client, but in the same respect as the request line.

still feel safe? :)

Posted in More on Filtering Input and Escaping Output.

Wed, 09 Feb 2005 at 20:36:33 GMT