The PHPClasses.org blog has a new post highlighting a vulnerability in the OAuth 2.0 specification that's been talked about quite a bit lately, the Covert Redirect Vulnerability. This issue allows potential attackers to trick users into redirecting to malicious sites and possibly gain access to personal information.

This vulnerability affects applications that implement protocols like OAuth 2.0 and OpenID. Lets see how this affects an OAuth 2.0 application. [...] The way it works is that your application redirects to a specific page of the Facebook site. There the user is asked if he wants to give your application permission to access Facebook API on his behalf. After the user agrees, his browser is redirected back to your site to a URL that your application specified called redirect_uri. From then on your site completes the process to get a special access token string that will be used by your site to access Facebook API on behalf of the user.

This token represents the user and can then be used to access the user's account. If that token fell into the wrong hands, they could access data they shouldn't. He includes a diagram of the flow and a link to a video explaining the problem in a bit more depth. He recommends three ways to help prevent this issue and what to look for in your implementation that could leave you vulnerable.

Michael Nitschinger has a "quick tip" posted in this new entry to his blog - how to handle a redirect in a Lithium-framework based application.

While migrating pastium over to MongoDB (from CouchDB), I found [a] snippet in the routes.php file [that makes it so] when the user enters the application via the root url (/), he instantly gets redirected to /pastes/add (or a different URL if you have custom routes configured). This may seem ok at first, but there's a problem. It doesn't take URLs into account that don't live directly under the document root.

The snippet he references and others showing how to correct the issue are included - replacing the location array controller/action information with the static class information for the route in a match() call. For more information on the routing in Lithium, see these manual pages.

On the SitePoint PHP blog today Craig Buckler has posted a new tutorial about redirecting old URLs - specifically WordPress ones - to their new locations.

We recently devised a system to redirect old URLs in PHP so that you could avoid "page not found" errors (I suggest you read it before venturing further). In this article, we'll create a similar system for WordPress, the popular PHP CMS. [...] There's probably no need to worry about redirecting old URLs if you’ve been using WordPress since day one. The system is reasonably good at finding the right page, even if you change your permalink structure.

They show a simple way to update your theme to catch the "not found" pages and redirect them to another script for handling. This new script takes the request and looks through an array of options to see if there's a match, then redirects if there is (via a 301 HTTP status response).

On the SitePoint PHP blog today there's a new post showing you how to create a 404 page that will redirect people back to the page they're looking for (that used to be there).

It's often necessary to reorganize your site and change the URL structure but, assuming you have similar content, users should rarely encounter a "page not found" error. Producing unnecessary 404 pages is one of my top 10 development mistakes. In this article, we'll create an automated PHP redirection system that converts old URLs to a new address. It's not production code, but it will illustrate the basics so that you can adapt it for your own website.

They walk you through the creation of a 404 error handling PHP page, configuring your server to use it and making the mapping of new URL to old URL. There's even a bit to include if there's not a mapping for a requested page - returning a 301 HTTP header.

One of the most popular reasons to use the header function in PHP applications is to do a redirect, but the webshop.com blog wants to remind you that there's more to it than just that.

If you are a web developer and you’ve ever worked with PHP you have probably come across the PHP header() function in the past. You most likely used it to implement a hard redirect; but you may not have understood exactly what was happening behind the scenes every time you call this handy function. Let’s take a look at what the header() function does and find some uses for it other than its most common use–redirects.

They look at what the header function is for, what HTTP headers are (and some examples) as well as a few examples of use outside of redirects including defining content types, response codes and cache control.

On DevShed today there's a new tutorial that walks you through tips on two things that can help you keep your https site running smoothly and keep in favor with the major search engines - duplicate content and correct 301 redirects.

When trying to maintain a secure protocol on an Apache-based website, you can expect to deal with certain issues, especially if you're also trying to rank well in the search engines. [...] This article provides tips and solutions to help any web developer effectively manage the two most difficult problems in maintaining the secure protocol side of any website. These are the: Duplicate content and 301 redirection from the non-https to http version.

They recommend two things to handle the duplicate content issues: placing a meta tag on the https pages to keep them from being indexed (keeping the search engines from seeing the http and htttps as two different resources, thus two different sites to index) and using a canonical value in a link tag.

As far as the 301 redirects go, they include some PHP code that, if placed at the top of your pages, can detect if the protocol is https or not. If its not, it uses header to perform the 301 redirect.

Recently on the Web Developement Blog, Olaf showed how to do a Location redirect with cURL while open_basedir is set.

If you need to follow redirects within your php code using Curl and the open_basedir is set you came into some trouble. If you disable this directive all your directories with a 777 permission are not safe (if one or more website on the same server has some security issues). If you don’t have additional protections you should NEVER disable the open_basedir directive (at least if you’re using 3rd party applications).

He writes up a simple cURL-based link checker to see which of the URLs in question would throw an error. He modifies it so that it checked the HTTP response code from the server and, if its a 200/302/301, you know things are okay and a shell_exec can be called to execute the file from that location.

WebReference.com has the second part of their CakePHP introductory series posted, this time focusing on the actions in the controllers.

They talk (briefly) about how the call to the page is passed off to the controller's action and how you can get more information into it via POSTed values.

There's also a look at redirection, from action to action in a controller (or even to another one) and a look at a very handy method of sharing functions between the child controllers - a "master" parent controller (in their case, AppController).

At the end, they throw in a bit about components - module and reusable bits of functionality that can be passed around from controller to controller, action to action.

This series of articles are excerpts from the Packt book CakePHP Application Development.

In a new post to his blog, Michael Kimsal points out a post from his brother (Mark) that wonders if your framework handles 404 errors the best/most useful way it can.

This post is about the consistency of frameworks. Consistency is key to a low learning curve. [...] Yesterday, my brother asked me how he could capture 404 errors in Cognifty, as he was building an app that relied on dealing with random URL patterns. [...] After talking for a bit, we decided that handing off the request to a standard service (or controller) was the best way to handle this type of "error". He started searching to see if other frameworks had a consistent, or at least documented, way of dealing with missing controllers.

In his research he found one framework - the Zend Framework - that handed them by default as an error and passed them off to that handler. Mark notes that, depending on your frame of reference, this may or may not be considered a true error.

His Cognifty framework handles things a bit differently. It allows you to change the presentation handler to redirect to another url if an error like a 404 is thrown - a technically "more correct" way of handling things.

On the PHP in Action blog Dagfinn Reiersol shares a method to send messages across a POST request that's followed by a redirect (versus a simple GET where it can be in the URL).

When processing a GET request, you can display whatever messages you want. The most simplistic way is to echo them directly; or if just slightly more sophisticated, set it in the template that's about to become the web page. When processing a POST request that is to be followed by a redirect, you can't do that. The response (redirect) sent back to the browser does not have any text or HTML content.

He points out two different ways to handle the problem - either manually append the message to the URL you're redirecting to or (a bit better method) store it in a session variable and remove it once its done. Several frameworks call this a "flash message". He gives examples of how to set this in two popular frameworks - Zend Framework and CakePHP.