Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Paul Jones:
PSR-7 and Session Cookies
Apr 12, 2016 @ 13:27:06

In this post to his site Paul Jones makes some suggestions about how to handle session cookies (PHP's default session handling mechanism) and requests/responses using the PSR-7 structure.

One of the great things about PHP is its session handling capabilities. One call to session_start() and a huge amount of heavy lifting is done for you. It’s a great aid when writing page scripts.

However, as you start to need finer control over the HTTP response in your project, some of the automatic session behaviors begin to get in the way. In particular, when you are using PSR-7 to build your HTTP response, you realize that session_start() and session_regenerate_id() both automatically do the equivalent of calling setcookie() to write headers directly to the output. This means you cannot buffer those calls into the Response object for later sending.

How then can we use PHP’s session handling, when we want finer control over when and how cookies get sent?

He suggests that you do two things. First, disable PHP itself from automatically sending the cookie via some ini_set calls. The second is to do the session ID comparison manually and perform the related action (either allowing or sending a new ID on failure). He includes example code showing it in action and also mentions some of the shortcomings of the approach around cache and limiter headers.

tagged: psr7 session cookie request response header disable tutorial

Link: http://paul-m-jones.com/archives/6310

Zend Developer Zone:
Z-Ray Tip #4: Getting Rid of It!
Jan 29, 2016 @ 10:44:14

On the Zend Developer Zone they've posted the fourth part in their series of tips around using the Z-Ray profiling tool in your PHP applications. In this fourth tip they show you how to "get rid of it" in certain parts of your application.

Well, while Z-Ray is a great friend to have when developing your apps, there are just some parties you don’t want it to show up at. You might be using PHP scripts for accessing static pages. Or, you might not want Z-Ray to be displayed for one specific request. In production, you most definitely don’t want Z-Ray popping up for users using your app!

There are numerous ways to disable Z-Ray both in development and in production to make sure your development workflow is not interrupted and your live apps are not affected. Here are a few of them.

They include a few different ways to disable the tool including the use of a function call in the code (zray_disable), using a header in the HTTP request and, naturally, from the Z-Ray toolbar itself. They also talk about setting it up to be removed for production in one of two modes, either selective (only showing for certain requests) and completely disabled.

tagged: zray tip disable development production api get header selective

Link: http://devzone.zend.com/7149/z-ray-tip-4-getting-rid-of-it/

Rob Allen:
Improved error handling in Slim 3 RC1
Sep 08, 2015 @ 12:23:52

Rob Allen has a quick post to his site talking about some of the improved error handling that's been updated in the latest version of the Slim microframework to help make reporting issues easier in multiple contexts.

From RC1 of Slim 3, we have improved our error handling. We've always had error handling for HTML so that when an exception occurs, you get a nice error page [...] However, if you're writing an API that sends and expects JSON, then it still sends back HTML. [...] At least we set the right Content-Type and status code! However, this isn't really good enough. We should send back JSON if the client has asked for JSON. Until RC1, the only way to do this was to register your own error handler.

With Slim 3 the framework handles things more correctly based on the value of the "Accept" header sent along with the request. This value is checked and, if it references JSON or XML, the error message is translated either giving the default output or reporting back for the "notFound" and "notAllowed" error types.

tagged: slimframework slim3 error handling context html json xml accept header

Link: http://akrabat.com/improved-error-handling-in-slim-3/

Matthew Weier O'Phinney:
On PSR7 and HTTP Headers
Jul 29, 2015 @ 09:47:59

Matthew Weier O'Phinney has a new post to his site talking about PSR-7 and HTTP headers and how they (headers) are handled in the structure of this PHP-FIG specification.

Yesterday, a question tagged #psr7 on Twitter caught my eye: "When I call $request->getHeader('Accept') for example, I was expected that I'll get [an array] but, in reality I got [a string]. Is this correct?" In this post, I'll explain why the behavior observed is correct, as well as shed a light on a few details of header handling in PSR-7.

He talks about the planning that went into PSR-7 and how they had to work around some of the "flexibility" (quirks) in the HTTP specification. This was especially true when it came to repeated headers. He also walks through their thoughts on multiple header handling and that custom header values are allowed. Because of these two things, they decided to treat all headers as collections and, despite there being separators already in the values. Instead they collected headers of the same types into these collections, some containing only one value while others could contain multiple. Back to the question - this explains why the "Accept" header they desired was still in its comma-separated form and not split into the array they expected.

The [...] example provides another good lesson: Complex values should have dedicated parsers. PSR-7 literally only deals with the low-level details of an HTTP message, and provides no interpretation of it. Some header values, such as the Accept header, require dedicated parsers to make sense of the value.
tagged: psr7 http header collection separator multiple single

Link: https://mwop.net/blog/2015-07-28-on-psr7-headers.html

Barry vd. Heuvel:
CSRF Protection in Laravel explained
Feb 23, 2015 @ 11:52:59

Barry vd. Heuvel has a recent post to his site explaining how the Laravel framework has implemented CSRF protection natively. CSRF is short for Cross-site request forgery and is a type of security vulnerability.

In this blog we take a closer look into CSRF protection in Laravel. We compare the difference between the CSRF filter in Laravel 4 and the current VerifyCsrfToken middleware in Laravel 5.

He start with a quick look at why CSRF protection is even needed and what kind of problems it can cause. He shows how the CSRF protection was enabled in the Laravel 4 routing and how, in Laravel 5, the token evaluation was updated to use the hash_equals to prevent timing attacks. He then gets into the details of the middleware and how it handles the protection for you (including detection and use of the X-CSRF-TOKEN header).

tagged: csrf protection laravel laravel5 middleware xcsrftoken header

Link: http://barryvdh.nl/laravel/2015/02/21/csrf-protection-in-laravel-explained/

Qandidate.com Blog:
Using the Accept Header to version your API
Oct 20, 2014 @ 12:56:46

On the Qandidate.com blog today there's a new tutorial talking about the use of the Accept header in REST HTTP requests and, more specifically, working with it in a Symfony-based application.

I investigated different ways to version a REST API. Most of the sources I found, pretty much all said the same thing. To version any resource on the internet, you should not change the URL. The web isn't versioned, and changing the URL would tell a client there is more than 1 resource. [...] Another thing, and probably even more important, you should always try to make sure your changes are backwards compatible. That would mean there is a lot of thinking involved before the actual API is built, but it can also save you from a big, very big headache. [...] Of course there are always occasions where BC breaks are essential in order to move forward. In this case versioning becomes important. The method that I found, which appears to be the most logical, is by requesting a specific API version using the Accept header.

He shows how to create a "match request" method in his custom Router that makes use of the AcceptHeader handling to grab the header data and parse it down into the type and API version requested. He also includes an example of doing something similar in the Symfony configuration file but hard-coding the condition for the API version by endpoint.

tagged: accept header rest api versioning symfony tutorial

Link: http://labs.qandidate.com/blog/2014/10/16/using-the-accept-header-to-version-your-api/

Jason Fox:
Use the Accept Header to Set Your Return Data With Zend Framework 2
Feb 22, 2013 @ 11:42:35

Jason Fox has a recent post to his site about using "Accept" headers in Zend Framework 2 apps to set the format of the return data from a request.

In this article I detail the process by which you can set up your controller actions in Zend Framework 2 to return either the default HTML, or JSON data depending on the “Accept Header” in the request. It incorporates changes related to a security update added since this very helpful article was written, and expands on some of the intricacies of making your web layer objects better “json providers.”

His example uses a "ViewJsonStrategy" and the criteria to look for to determine which version to respond with (HTML or JSON) - the Accept header. It uses the JSON encoder/decoder instead of the built-in PHP one to he could use the included "toJson" method to customize the output of the JSON instead of just returning everything.

tagged: accept http header zendframework2 tutorial json

Link:

PHPMaster.com:
REST - Can You do More than Spell It? Part 4
May 21, 2012 @ 08:44:26

PHPMaster.com has posted the latest tutorial in their series covering RESTful APIS - part four of "REST - Can you do More than Spell it?" In this latest part of the series, they focus on something very key to RESTful services, the HTTP spec (and headers).

We're getting close to the end now, and the only thing remaining is to discuss a little more about the protocol you'll most likely use in any RESTful application that you write. Because HTTP is so often used with REST, that's the protocol I'd like to focus on.

He goes through the structure of a typical (raw) HTTP header and talks about some of the more common headers and what actions/settings they represent. He includes examples of setting headers (with header, naturally) and a curl example showing how to set the request headers. The tutorial is finished off with a brief mention of custom HTTP headers and the the good and bad that comes with them.

tagged: rest api tutorial series http spec protocol status header

Link:

Phil Sturgeon's Blog:
Hijacking Headers to Force Downloads
Mar 29, 2012 @ 11:29:28

Phil Sturgeon shows how you can hijack headers in his latest post to force a download to the client (even on a hosted service like PagodaBox).

The question [I posed on Twitter] was: "How to force a download of any file of any type, not on your server, without Apache tweaking? Images are displaying and need em to download." Essentially, I wanted to be able to link to a file that was not on the server in question and anywhere in the world, which could be of any size, any media type and could be potentially very high traffic.

Answers varied from using readfile to just letting the browser handle it. None of the responses were quick right until he came across one that recommended some settings in an .htaccess file. It uses

tagged: file download force header question htacess

Link:

DashExamples.com:
Add a Content Security Policy(CSP) to your Web Site with PHP
Aug 25, 2011 @ 13:11:36

Related to this other post about content security policies in PHP sites, DashExamples.com has a quick new post about what you'll need to add to your application to implement a policy of your own.

Content Security Policy(CSP) is a mechanism in the browser that restricts what content will be requested and run by the browser. CSP does this by passing in a specific response header that tells the browser what resources (images, javascript, css, frames, etc) can be requested and accepted to execute. There are multiple ways to setup CSP for your web site, you can use your web server configuration like I showed in a previous example or use a dynamic scripting language like PHP.

What it really boils down to is setting a header, either X-Content-Security-Policy or X-Content-Security-Policy-Report-Only, to tell the browser what security policy to use and how to honor it. You can find out more about content security policies from this page on the Mozilla wiki. CSPs allow you to define how your site's content interacts and help to prevent issues like XSS and data injection.

tagged: content security policy tutorial header

Link: