Getting Away from the Web

This chapter takes a look at the basic steps involved in breaking free from the Web with PHP. I’ll cover the technical steps involved and also the differences in programming practices and focus.

PHP Without a Web Server

Most PHP programmers have used PHP strictly in a web server environment. In such an environment, PHP is a CGI/Fast GGI or server module called and controlled by the HTTP server (usually Apache, IIS, Nginx, or similar). The HTTP server receives a request for a PHP-based web page and calls the PHP process to execute it, which usually returns output to the HTTP server to be sent on to the end user.

There have been a number of attempts to create local applications (scripting systems, desktop apps, and so forth) with PHP using a locally installed web server, with some success. However, the downsides of using this web-type model for local apps are numerous.

• For the value they provide in these scenarios, web servers such as Apache are often over-specified and resource-hungry.

• Unless properly locked down, a web server running locally introduces a point of access to your machine for malicious visitors from the outside world.

• HTTP is a verbose protocol and (arguably) ideally suited for the Web. However, it’s often overkill for local interprocess communication and adds another resource and complexity overhead to your application.

• Your application interface typically runs in a web browser and therefore looks anything but local (and comes with additional support/upgrade headaches unless you install a browser specifically for your app).

PHP, as of version 5.4, includes a built-in web server, which removes some of the problems described earlier. However, it was designed for local testing of PHP scripts designed to be deployed on a fully fledged HTTP server such as Apache in a live environment. It is a route that can be explored for some local apps, particularly where you want to run a private instance of a PHP web app that already exists. However, its stability, reliability, and suitability for production-ready local apps are yet to be proven, and it still comes with the baggage of HTTP and web browsers.

Since version 4.3, PHP has had an ace hidden up its sleeve that solves all of these problems. The PHP CLI Server Application Programming Interface (SAPI), to give it its formal name, is essentially a long way of saying “stand-alone PHP.” It cuts out the need for a web server and provides a stand-alone PHP binary for you to interact with. For instance, typing the following at a shell prompt

∼$ php /home/myfiles/myprogram.php              

will simply execute your myprogram.php file (which you write mostly like any other PHP script) and return any output to the terminal (unless you tell it otherwise) instead of being sent to the web server (which doesn’t exist!).

In general, PHP scripts called directly using the PHP CLI SAPI will behave in the same way as when called through a web server, although there are some differences. For instance, you won’t find any $_GET or $_POST arrays, and PHP won’t send any HTTP headers by default; these concepts don’t mean much beyond the Web. Default settings such as max_execution_time are set to sensible values for local use (in this case to 0 so your scripts won’t time out), output buffering is turned off, and error messages are displayed in plain text rather than HTML.

Chapter 3 gives full details of how to install (if necessary) and use the CLI SAPI.

PHP Versions: What’s Yours?

PHP has supported the CLI SAPI since version 4.3.0, so many of the examples in this book will run on any PHP version since then. At the time of writing, the current version of PHP is 7.02, and the code in this book has been tested against this version. If you find that a particular function doesn’t appear to exist or work as expected, check the online PHP manual for that function. The manual shows which versions support which functions and describes any breaking changes created by newer versions.

If you are using an older version, there are some good reasons to upgrade.

• Performance has increased markedly (and, correspondingly, the resources used have decreased) in recent versions.

• Although security is not always as critical with nonweb applications (see the discussion in “Thinking About Security” later in this chapter for caveats), the security enhancements and security-related bug fixes in recent versions are essential if you’re handling data from external sources and if you’re using the same version for web work as well.

• Modern language features are available, which can help your coding productivity as well as help others take your code more seriously.

As with the web versions of PHP, you can compile your own version of the CLI SAPI if you find the need. If you want to include extensions not prepackaged by your OS software repositories, remove nonessential code for performance reasons, or use any of the other compile-time options that PHP supports, then learning to “roll your own” version may be worthwhile. You can find a starter guide to compiling and installing PHP and related extensions in Appendix A.

A Few Good Reasons Not to Do It in PHP

Tell someone you’re going to be writing CLI scripts in PHP and often they’ll rail about how PHP is a web language and that you should choose a language “more suited” to the task. This book is focused on doing everything in PHP, and for 90 percent of tasks, PHP will do all that is asked of it. PHP is now a general-purpose language, it’s Turing complete, and while it’s still used in the main to run “websites,” more and more that means back-end services as well. But before you commit to rewrite your world in PHP, there are a few pertinent issues that you may want to consider carefully before jumping in.

Thinking About Security

Every good programmer is at least aware of the security implications of building websites and online apps. You deliberately expose your code to the public, to the world, and to anyone and everyone who will come (good people and bad). One of the early failings of PHP was to prioritize ease of use over security of code (the horror stories from relics like register_globals are only a quick Google search away). With newer, more secure defaults and functions like register_globals being depreciated, PHP is safer than ever online. And although most security problems are caused by the programmer rather than the language, even the newest web coders seem to have an appreciation of security issues from day one these days.

Step into the world of offline software, however, and things are markedly different. Typically we see software for trusted users only, deployed locally on trusted machines and under the full control of the benevolent user. The user isn’t going to deliberately attack the software or machine; they’re working with their own data. Functionality absolutely can’t be compromised. Security is rarely considered at all when developing command-line programs and desktop apps, let alone being features specified at design time, because it’s not “necessary.”

Except the world doesn’t work like that. Take a look at any software vulnerability mailing list like BugTraq and you’ll find an abundance of vulnerabilities in “offline” apps such as Adobe Reader, Microsoft Word, and even open-source stalwarts like GIMP. The fact is, security is important even in local apps, for two main reasons. The first is the perennial problem of “typical user” behavior. This is not a problem for an intelligent tech-literate user who never makes mistakes (like you, dear reader), but for any software used by the rest of us disaster is only an accidental-click-on-a-dodgy-e-mail away. The second reason security is important is that for most machines, many nonweb applications aren’t really “offline.” Even when a desktop app or a system daemon doesn’t interact with the Web, local network, or other external services itself, the machine it is connected to will invariably have an Ethernet cable plugged into it or a WiFi/3G/4G connection active. Your software will not run in its own cozy little realm, insulated from the world outside (perfectly sandboxed virtual machines notwithstanding, of course).

Software security is the topic of a whole other book (of which others have written plenty; see the “Further Reading” section), and many of the same principles apply to systems software as to web software, so you will be able to use your existing knowledge of web-based PHP security practices to guide you. The following list of typical vulnerability types and attack vectors in both user-facing and systems software should be considered when planning your script security measures and monitoring:

• Compromised filesfrom external sources (loaded deliberately or accidentally by users): These are usually data files, and particularly at risk is software registered as a default viewer for a particular file type because accidental and malicious file activation is much easier.

• Malware looking for innocent software to exploit to gain privilege escalation: Scripted software like PHP code can be easier for malware to rewrite or alter, and the availability of the source code in an uncompiled form can be of help to the malware authors.

• Legitimate users misbehaving: John Smith is looking for a way to view the files or surfing history of his boss, Jane Doe, on their shared business system, for instance.

• Privilege escalation: Similar to legitimate users misbehaving , this is legitimate software misbehaving, either accidentally or deliberately trying to gain and use access permissions it does not have.

• PHP vulnerabilities and vulnerabilities in other dependencies and related software: Your software will be completely free of security issues, of course, but it invariably depends on other libraries, software, and PHP extensions, and of course let’s not forget the PHP interpreter. Any of these can contain security bugs and attack vectors.

The previous are common sources of security issues in all types of software, not just in PHP. Minimize your risks by planning for these in the design stage and testing for them before deployment. Then cross your fingers.

CLI-Specific Code Frameworks

There are many coding frameworks for PHP, and many of them can be used with CLI applications, although only one is specifically created for nonweb programming. Code in various frameworks may assume that it will be called in an HTTP-related context, so you may need to do extra work to code around this. When deciding whether to use a framework, or which one to use, you should bear in mind their applicability (in terms of their focus on the Web) and whether your application’s performance will suffer from the overhead they may bring. You will usually also need to look at their license because they will usually have components that need to be distributed with your scripts. That’s not to say they can’t be useful in general-purpose programming; however, there are none that I can at this time recommend specifically for nonweb projects. If you’re currently comfortable using a particular framework on your web projects, it may be worth seeing whether there is a “CLI” or “console” module or recommended code path for that particular framework.