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.

During vulnerability assessment or penetration testing, identifying the input vectors of the target application is a primordial step. Sometimes, when dealing with Web application testing, verification routines related to SQL injection flaws discovery are restricted to the GET and POST variables as the unique inputs vectors ever. What about other HTTP header parameters? Aren't they potential input vectors for SQL injection attacks? How can one test all these HTTP parameters and which vulnerability scanners to use in order to avoid leaving vulnerabilities undiscovered in parts of the application?

They start by describing the different kinds of headers that the attacks could come in on - GET, POST, cookies and the other HTTP headers. According to some results, the HTTP headers option is the least protected in most common applications. He includes some good examples of headers that might contain malicious data such as:

• X-Forwarded-For
• User-agent
• Referer

Techniques are also included showing you tools and methods to help test your own applications including some in-browser tools and external applications (like Sqlmap, Nessus, WebInspect, SkipFish and Wapiti) with some average scores from running them on various coverage scores.

I've written about Google and OAuth before, but that was OAuth v1.0, and they are introducing OAuth2 for their newer APIs; in this example I was identifying myself in order to use the Google Plus API. [...] OAuth 2 doesn't need an extension or any particular library as it doesn't have the signing component that OAuth 1 had, and OAuth 2 also has fewer round trips. It does require SSL however, because the requests are in the clear.

She includes some code snippets with an example of a connection - making a request to the remote HTTPS resource, adding some parameters to the URL (including the response type, your client ID and a redirect url). The response then contains the "code" value you'll need to make the second request to fetch the access token you'll need on future requests. You can find out more about the interface she's accessing in these docs about the Google Plus API.

Today what you get is an example of integrating with JIRA's REST API, because their recent "upgrade" locked me out of the issue listings pages completely and I really do need to be able to see a list of bugs! Their bug editing screen is quite usable, so it's just the list that I need here, but you could easily call their other API methods as you need to. These examples are PHP and use the Joind.in Jira tracker), parsing the JSON results and displaying the results as a simple list, looping with a foreach and outputting some HTML.

]]> Wed, 28 Mar 2012 10:57:56 -0500 http://www.phpdeveloper.org/news/17456 http://www.phpdeveloper.org/news/17456 Mike Wallner has shared a quick and easy HTTP caching technique in a new post to his blog today. The key is in using the PEAR HTTP_Header package.

Ever watched youself browsing e.g. a web forum? Noticed that you viewed the same page several times? Well, this means extraordinary and useless load for your server if there's no caching mechanism implemented in the web application. Even if there is some file or db cache you can still improve performance with implementing some http cache.

With a few simple lines of code using HTTP_Header, you can tell your scripts how long to set the "expires" header to on your requests. This increment (in seconds) is relayed to the browser to tell it when to next fetch the page and not reload from cache.

]]> Fri, 27 Jan 2012 09:43:04 -0600 http://www.phpdeveloper.org/news/17256 http://www.phpdeveloper.org/news/17256 In a recent post to his blog Chris Hartjes looks at the idea of better HTTP Request/Response functionality in PHP, more than just the superglobal handling and PECL HTTP extension it has now.

I think the fact that we have $_POST and $_GET lulls some of us into the false sense that we should have $_PUT and $_DELETE objects, since that would map to the commonly-desired set of HTTP verbs that REST likes to use. But what should be inside those things, or should we be moving towards a more Pythonesque solution where a Request object, as part of core or via a only-really-for-the-brave- PECL extension?

He mentions opinions from other PHP community members (Laura Thompson and Elizabeth Smith) and a bit about what he (and I'm sure other developers) are looking for in a more full-featured request/response handling feature.

]]> Wed, 14 Dec 2011 09:51:03 -0600 http://www.phpdeveloper.org/news/17252 http://www.phpdeveloper.org/news/17252 Chris Hartjes and Ed Finkler (two well-known PHP community members) have started up a podcast where they talk about, basically, whatever they want in their "piss-and-moan-driven-development" style. In their first episode, they talk about what they hate about PHP.

Listen to a couple old dudes complain that they don't like PHP anymore. Yes, I know, this sounds pretty compelling.

They specifically mention the PUT method support in PHP. You can download the mp3 (about an hour and a half long) and check out the two hosts on Twitter: Chris and Ed.

]]> Tue, 13 Dec 2011 13:16:19 -0600 http://www.phpdeveloper.org/news/16876 http://www.phpdeveloper.org/news/16876 On PHPBuilder.com today there's a new tutorial showing how to use libcurl to communicate with multiple protocols like FTP, HTTP, HTTPS, SMTP and STMPS. The libcurl library that can be compiled in or installed as a shared module in your PHP install to provide enhanced networking abilities.

As I wrote in my PHP multithreading with cURL article, the libcurl is a free and easy-to-use client-side URL transfer library, supporting DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMTP, SMTPS, TELNET and TFTP. PHP supports the libcurl library which allows you to connect and communicate to many different types of servers with many different types of protocols.

The tutorial focuses on two different types of connections (well, four really) - FTP/FTPS and HTTP/HTTPS - and how to transfer data across each. Some code is included to create a (procedural) tool to send an uploaded file to a remote site.

]]> Mon, 19 Sep 2011 12:03:23 -0500 http://www.phpdeveloper.org/news/16649 http://www.phpdeveloper.org/news/16649 Anthony Wlodarski has put together a new post to his blog talking about authenticating a Zend Framework app against Node.js with the help of the Socket.io component for handling credentials.

Zend Framework which is PHP based and Node.js which is JavaScript based don't have a common connection to pass data in a bi-directional nature. I was tasked with building a bridge of sorts that would utilize existing information from Zend Framework with the latest release of Socket.io's authorization mechanisms. (If you don't do this then arbitrary connections can happen and will be authorized.)

He starts with the code (on the Node.js side) to create a simple HTTP server to listen for the requests from the Zend Framework application. He gets into the details of how that all works before moving to the other side - a simple update to the authentication to store a session cookie with the information that is passed, via Socket.io to the waiting Node.js server for handling.

]]> Thu, 28 Jul 2011 13:41:28 -0500 http://www.phpdeveloper.org/news/16612 http://www.phpdeveloper.org/news/16612 In a new post to DZone.com today Giorgio Sironi asks developers what new feature of PHP 5.4 is the most important to you and your application development?

Recently, the voting process for PHP 5.4 open to committers and users have been closed. We now have a clear picture of what will make the release and what will be left out. Some of these features (traits, web server) were already in, while other have been just voted and will be completed before the general availability of the release.

He lists out some of the major changes that'll be coming in the 5.4 release including traits, dereferencing, the built-in HTTP server, closure type hinting and the upload progress feature previously only in an extension. The end of the post includes a poll for you to give your feedback on what you think is the most important. As of the time of this post, the array dereferencing has pulled into the lead with traits coming in second.

]]> Wed, 20 Jul 2011 10:14:59 -0500