3

Links for Tue 19 Feb 2008

Posted on February 19th, 2008 / 3 Comments »
Tags: , , , , ,
0

Links for Thu 7 Feb 2008

Posted on February 7th, 2008 / No Comments »
Tags: , , , , , , ,
0

Links for Thu 17 Jan 2008

Posted on January 17th, 2008 / No Comments »
Tags: , , , , , , , ,
0

Links for Mon 14 Jan 2008

Posted on January 14th, 2008 / No Comments »
Tags: , , , , , , , , , , ,
0

Links for Mon 14 Jan 2008

Posted on January 14th, 2008 / No Comments »
Tags: , , , , , , , , , , ,
3

Links for Tue 8 Jan 2008

Posted on January 8th, 2008 / 3 Comments »
Tags: , , , , , , , , , , , , , , ,
1

Links for Tue 13 Nov 2007

Posted on November 13th, 2007 / 1 Comment »
Tags: , , , , , , , , , , , , ,
0

Links for Thu 8 Nov 2007

Posted on November 8th, 2007 / No Comments »
Tags: , , , , , , , , , ,
1

Links for Wed 7 Nov 2007

Posted on November 7th, 2007 / 1 Comment »
Tags: , , , , , , , , , , , ,
0

Links for Mon 6 Dec 1999 through Tue 6 Nov 2007

Posted on November 6th, 2007 / No Comments »
Tags: , , , , , , , , , , , , ,
0

Links for Sun 5 Dec 1999 through Mon 5 Nov 2007

Posted on November 5th, 2007 / No Comments »
Tags: , , , , , , , , , , , ,
0

SQL Server Extension for PHP from Microsoft

Posted on October 25th, 2007 / No Comments »
Tags: , ,

Earlier this month Microsoft contributed a SQL Server Driver for PHP. They even have a SQL Server and PHP blog and their SQL Server forum now lists as PHP in their client list. The blog has an interesting post on development of the driver.

So, what does this thing do? It is for PHP5 only (not a big deal considering PHP4 will only be getting security updates after this year) on Windows (this part is a bummer, but not surprising) to access SQL Server 2000 and 2005 (anyone running anything older than that in production?).

You could work with SQL Server from PHP prior to this using FreeTDS. I’ve used the mssql_* PHP functions backed by FreeTDS on FreeBSD for years so this new driver from Microsoft isn’t a major game changer at this point.

That said, I find this a pretty exciting development.

Microsoft is actually providing a PHP library to work with some of their own software. I think that is great, although the really huge win would have been if it was available for non-Microsoft operating systems. This is great stuff though, not just talk, but real live code. Combining this with better PHP on IIS support I have a glimmer of hope that we’ll see more good things from Microsoft for PHP.

There has been plenty of PR about Microsoft doing more in this area, but providing real code and tools is what we actually need.

0

PHP on IIS

Posted on September 24th, 2007 / No Comments »
Tags: , , , ,

Microsoft’s IIS.net site has a new section: PHP on IIS. This is kind of strange on several levels. First off is the idea of Microsoft supporting non-Microsoft server side languages in IIS. Yeah, you’ve been able to do this for a long time (I remember running a perl ISAPI module in IIS in the 90s), but quite frankly it wasn’t that great. Just getting it to run usually involved way too much voodoo. It looks like we are starting to get something that resembles official support for PHP on IIS.

Another strange think is that this was announced in conjunction with their Go Live release of FastCGI for IIS 5.1 and IIS 6.0. Those using IIS 7 will have to wait until Vista SP1 or running Server 2008 Beta 3 or better. I suppose IIS 7 doesn’t have a large share of the IIS web server market so perhaps it isn’t much of an issue.

It looks like FastCGI will be the official way to run PHP on IIS going forward.

The IIS.net site has some documentation on how to get various PHP apps running on IIS, including WordPress on IIS.

My first choice is still a un*x box though :-)

28

HTTP Basic Authentication, A Tale of AtomPub, WordPress, PHP, Apache, CGI and SSL/TLS

Posted on September 19th, 2007 / 28 Comments »
Tags: , , , , , , ,

I’ve been really enjoying working with Tim Bray, Pete Lacey, Elias Torres and Sam Ruby on improving AtomPub in WordPress. This work is in WordPress 2.3, which will be released later this month. You can try it out right now by downloading the beta. Sam has also started some documentation on AtomPub in WordPress at http://codex.wordpress.org/AtomPub.

There is a lot of ground to cover in the post so to start with I want to distinguish between two topics that are closely related, but for our purposes today are also separate and distinct from each other. The first is authentication, specifically HTTP Basic Authentication. The second is security, which will focus on SSL/TLS (i.e. using https:// URLs).

To start with, the AtomPub spec has a section on Securing the Atom Publishing Protocol that deals with authentication. In general, you can use nothing or what ever you want, but HTTP Basic Authentication with TLS needs to be able to work. Think of it as HTTP Basic Authentication being the lowest common denominator that AtomPub clients and servers have to support, along with TLS if you’d like.

In WordPress there are actually two ways that a user could be authenticated when using AtomPub, HTTP basic and cookies. The cookie mechanism just looks to see if you sent along an authenticated WordPress cookie with your request. Since we’d been using Tim’s Atom Protocol Exerciser (APE) for testing, all authentication was being done via HTTP basic. Which worked fine, most of the time.

I started running APE against WordPress running under different situations and I ran into a problem with authentication when PHP was being run as a CGI under Apache. When running as a server module (mod_php) PHP takes care of decoding HTTP basic for you (see HTTP basic authentication in PHP). When a using HTTP basic PHP will automatically populate $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'] variables with the username and password that were provided. IF and ONLY IF PHP is being run as a server module (like mod_php). If you are running PHP as a CGI then those two variables won’t get created at all, ever, even when using HTTP basic authentication. And since you can’t do anything in WordPress via AtomPub without authenticating you are dead in the water. Well, not exactly.

PHP not supporting HTTP basic auth when being run as a CGI is a known issue, so folks have come up with clever work ways to work around this. One common work around is to use mod_rewrite to add HTTP basic auth into $_SERVER['HTTP_AUTHORIZATION']:

RewriteEngine on
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization},L]

The idea here is that mod_rewrite watches for an HTTP basic auth attempt and then injects the HTTP header in to the PHP environment as HTTP_AUTHORIZATION. From there is it an easy job of parsing and decoding the HTTP header and manually populating $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'] yourself. This is currently being done in the WordPress AtomPub code, so if you are on a host that runs PHP as a CGI and you have access to .htaccess and mod_rewrite then you can try it out.

Unfortunately I’ve seen times where this doesn’t work either. A modified version of this that I’ve had better success with is to pass the authentication back in via GET. Here’s an example from a test WordPress blog that redirects AtomPub authentication:

RewriteEngine on
RewriteBase /test/atompub/
RewriteCond %{HTTP:Authorization}  !^$
RewriteRule wp-app.php wp-app.php?HTTP_AUTHORIZATION=%{HTTP:Authorization} [QSA,L]

Instead of parsing and decoding from $_SERVER['HTTP_AUTHORIZATION'] you would do it from $_GET['HTTP_AUTHORIZATION']. This isn’t exactly ideal either, but I’ve had better luck getting it to work in PHP as a CGI environments. Code to support this isn’t in WordPress AtomPub yet, but we might add it.

The four of us went back and forth on this a bit then Tim Bray asked the elephant in the room question: why doesn’t PHP support HTTP basic when running as a CGI? I didn’t have a good answer for him, so I went hunting on Google. It turns out that this has nothing to do with PHP, it is how Apache works. Apache does not pass the HTTP basic headers to CGI applications, so they never see them. This has been mentioned in several places, for brevity I’ll only quote one, from Jon Udell talking about CGI and mod_perl:

HTTP Authentication

“Note that such a module has complete access to the HTTP headers sent by the client. If you write a CGI script to enforce a security policy, à la the ByteCal example above, that script will normally see only the user’s name (HTTP_REMOTE_USER) and not the full credentials (HTTP_AUTHORIZATION).

That’s because Apache, as a security measure, withholds the Authorization header from CGI scripts. (If you really want to build a CGI-based access-control script, you can tweak Apache to make it send this header.) But an Apache/Perl authentication module, running inside the server, knows everything that Apache knows about a request.”

So far I’ve used WordPress and AtomPub as an example, but this problem is not specific to either. This is an issue with CGI applications being able to use HTTP basic authentication, and the ways people have worked around it. While there are ways to deal with this (like the two I mentioned above), they aren’t ideal and only work if you can use .htaccess and mod_rewrite.

There have been lots of alternatives to authentication that get around this issue. Lots of people have looked at this, hopefully we’ll have a generalized way of dealing with this at some point. Until then it looks like we’ll see API specific variations of authentication.

Ok, I also mentioned that we’d talk about security. This one is more to the point, if you aren’t using SSL/TLS then your communications aren’t secure. Although HTTP basic doesn’t send your plain text password and username, it is the next best thing (base64 encoded). So anyone with access to your traffic (wireless network sniffing anyone?) can easily grab your username and password. So how do you secure this authentication process? By doing it over SSL/TLS. If your web traffic isn’t using SSL/TLS it isn’t secure.

In the context of WordPress there is a trade off here. We can’t guarantee that every WordPress install is going to support SSL/TLS, so we can’t make it a requirement. That said, there is nothing in WordPress (or the APIs: AtomPub and XML-RPC) that prevent you being able to use SSL/TLS. This leaves it up the person running the WordPress blog to decide what level of security is needed.

On WordPress.com we support TLS/SSL. You can point your XML-RPC client at https://<your_blog_here>.wordpress.com/xmlrpc.php and it will encrypt the data back and forth between your computer and WordPress.com servers. Same for AtomPub, only the URL would look like https://<your_blog_here>.wordpress.com/wp-app.php.

Hopefully everyone takes away two things from this. One, you can’t depend on HTTP basic authentication working. Two, if you aren’t using SSL/TLS then your traffic isn’t secure.

1

PHP4 No More?

Posted on July 13th, 2007 / 1 Comment »
Tags:

Just a day for talking about PHP I guess :-)

PHP 4 end of life announcement:

Today it is exactly three years ago since PHP 5 has been released. In those three years it has seen many improvements over PHP 4. PHP 5 is fast, stable & production-ready and as PHP 6 is on the way, PHP 4 will be discontinued.

The PHP development team hereby announces that support for PHP 4 will continue until the end of this year only. After 2007-12-31 there will be no more releases of PHP 4.4. We will continue to make critical security fixes available on a case-by-case basis until 2008-08-08. Please use the rest of this year to make your application suitable to run on PHP 5.

The clock is ticking, with about 200 days of PHP4 releases remaining, after that all bets are off. What I was really hoping as part of this announcement is a commitment to a PHP6 time line. I’m sure there are plenty of people who would rather just go directly to PHP6 instead. I think they should have waited to make this move until the first PHP6 release.

« Older Entries

Tags

Ads