Flash, like JavaScript, more-or-less adheres to a same-origin policy by default. Under a same-origin policy, requests for data must come from the same scheme, hostname, and port. If http://foo.example tries to request data from http://bar.example, the request will usually fail.

Same-origin policies are designed to prevent the unauthorized leakage of data to a third-party server. Without it, a script or SWF hosted on http://mightbeevil.foo could read data hosted on http://goodsite.foo and send it to http://muhahahaevilsite.foo. This kind of cross-domain activity could be used to exploit cookie and authentication data. It’s clearly a bad thing.

Recent browsers have safeguarded against these kinds of cross-site scripting exploits by preventing JavaScript from making cross-origin requests. XMLHttpRequest, for example, will throw a security exception if you attempt a cross-origin request.

Flash, meanwhile has long supported a means for enabling cross-origin requests: the policy file. The policy file is a way of white-listing requests for data or credentials from specific origins. It lives on the server from which you are requesting data, and gives the Flash player a “yay” or “nay” when asked whether the request from a specific origin should be allowed to complete.

Cross-origin restrictions, though necessary, are also quite limiting. You can’t (or couldn’t), for example, request data for a mash-up using XMLHttpRequest. Though there are workarounds — using dynamic script insertion, or using the document.domain — those workarounds also leave the DOM vulnerable to cross-site scripting.

To to mitigate the dangers of cross-site scripting while still enabling it, the W3C is developing the Cross-Origin Resource Sharing (CORS) specification. It functions similarly to Flash’s cross-domain policy file, but uses HTTP headers instead of an XML configuration file.

CORS request headers are automatically generated by conforming browsers when a script attempts a cross-domain request. Response headers must be set in the server’s configuration file, or dynamically per URL using a server-side language.

Let’s compare a sample cross-domain.xml file to how we’d achieve the same thing using CORS.

Cross-origin requests from Flash

To use the domains from our example above, if http://mightbeevil.foo made a request to data hosted on http://goodsite.foo, http://goodsite.foo would need to permit the request by including mightbeevil.foo it in its policy file. For example:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="mightbeevil.foo"/>
</cross-domain-policy>

This file must be stored in the web root of http://goodsite.foo. It explicitly permits mightbeevil.foo — and permits only mightbeevil.foo — to make requests for its data (from within a Flash movie).

Cross-origin requests from the DOM

To reuse our example from above, let’s use XMLHttpRequest to make a request from http://mightbeevil.foo to http://goodsite.foo.

var xhr, onLoadHandler 

onLoadHandler = function(event){
     alert('It is done!');
}

xhr = new XMLHttpRequest();
xhr.open('GET','http://goodsite.foo/data.json');
xhr.onload = onLoadHandler;
xhr.send(null);

It looks just like a regular XHR request, except for the fact that we’re requesting data from another origin. Let’s take a look at our headers.

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding:gzip, deflate
Accept-Language:en-us,en;q=0.5
Connection:keep-alive
Host:goodsite.foo
Origin:http://mightbeevil.foo
Referer:http://mightbeevil.foo/make_cross_domain_request/
User-Agent: Awesome/9.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) FantasticEngine/8889876 Awesome Browser/9.0

Notice that our headers include Origin:http://mightbeevil.foo.

Goodsite.foo responds with the following headers.

Access-Control-Allow-Origin:http://mightbeevil.foo
Connection:Keep-Alive
Content-Length:1349
Content-Type:application/json
Date:Mon, 26 Sep 2011 04:44:50 GMT
Keep-Alive:timeout=5, max=100
Server:Apache/2.2.20

Here we see that an Access-Control-Allow-Origin response header is returned by the server. Like allow-access-from, it indicates which domain(s) are allowed to make requests. Here, we want to know whether mightbeevil.foo is allowed to request data. It is, so the request will be completed.

Acceptable values for Access-Control-Allow-Origin include an origin (scheme + host + port), a comma-separated list of origins†, or a wildcard (*). As with cross-domain.xml, if the value of Access-Control-Allow-Origin had instead been http://notevil.foo, the request would have failed. Using a wildcard allows requests from any domain.

Of course, both specifications are more complex than what I have covered here. These examples illustrate how to enable a basic cross-origin request. It is also possible with both CORS and Flash to permit or exclude custom headers. And in the case of CORS, it is possible to use methods such as PUT or DELETE if the user agent supports it.

Learn more

• Flash cross-domain policy file specification
• Cross-origin Resource Sharing
• XMLHttpRequest Level 2

† Most browsers do not yet support multiple origin values. The specification is also a working draft, and subject to change.

Winer’s explanation is purely speculative, and some might call it a conspiracy theory. But it points to a big issue for free speech in the cloud: what happens if one, smaller customer criticizes a bigger customer? In the Web 1.0 era, if you got kicked off a Web host you just found another. Today, the number of providers like AWS are small. As AWS’s promotion material points out, cloud computing gives smaller outfits the ability to take advantage of high-performance computing.

So are Amazon and Apple jeopardizing small(er)-fry companies to keep their lucrative Federal contracts? What does such action mean for customers of all sizes? That’s what Klint Finley asks in Read/Write Web’s Amazon Web Services, WikiLeaks and the Elephant in the Room.

I half-assedly make DVD backups of my blog data and important files. But that stuff changes so frequently that a DVD system is really inadequate. An external hard drive is great for on-site backups, but hard drives and DVDs are subject to the same vulnerabilities. What do I do if:

1. the hard drive fails or the DVD gets scratched?
2. the hard drive gets lost or stolen?
3. the hard drive or DVD gets destroyed in a fire?
4. I do some dumb sh*t like accidentally knock over a glass of wine onto the hard drive.

Yeah, an external storage solution is so the right idea.

Enter Amazon.com’s Simple Storage Service, part of the company’s web services offerings. Until recently, the program was only useful for developers. S3 uses REST and SOAP to send and retrieve data. If you didn’t know what to do with either of those, good luck taking advantage of the service.

Since S3′s launch, however, a few companies and developers have created easy-to-use interfaces for interacting with S3. Now just about anyone can take advantage of S3 to store data.

Why would you do such a thing? Three words: S3 is cheap. You can calculate just how cheap. Simply pay for what you use. And unlike with most online backup services, you have the added ability to manipulate your data using standard protocols. There’s some serious media serving potential there, particularly if coupled with Amazon’s Elastic Compute Cloud.

For storing and retrieving data you have quite a few options. Here are four of my picks:

JungleDisk

• Operating system(s): Mac, Windows, Linux
• Cost: $20; unlimited installations
• Basics: Mounts like a disk drive, allowing you to easily upload and download files.

S3 Backup (Beta version)

• Operating system(s): Windows
• Cost: Free for now. Beta versions have set expiry dates.
• Basics: Easy-to-use upload/download utility. Interface operates much like any other FTP software.

Transmit 3.6

• Operating system(s): Mac OS X
• Cost: $29.95
• Basics: Fabulous FTP software for Mac with support for S3 in the same familiar Transmit interface.

Amazon S3 Firefox Organizer (S3Fox)

• Operating system(s): Mac OS X, Windows, Linux — any platform that can run Firefox
• Cost: Free(-ish; Don’t be a freeloadin’ jacka**. Make a donation)
• Basics: A Firefox extension with an interface similar to FireFTP. It functions in much the same way.

Do you use S3? What tools have you used to store and retrieve data? Do you prefer another online storage service? Make your case in the comments.

Sample re-write rules using mod_rewrite. These would be included in your .htaccess file for the directory whose URLs you wish to rewrite. More exacting patterns / rewrite rules are possible.

RewriteEngine On
RewriteBase /

RewriteRule ^requested_directory$ index.php?page=$0
RewriteRule ^requested_directory/$ index.php?page=$0
RewriteRule ^requested_directory/.*$ index.php?page=$0

Above: ^ starts the beginning of the pattern. $ designates the end of a pattern line. A period indicates ‘any single character.’ the * means ‘0 or N of the preceding text’ (where N is greater than 0).

The stuff after the $ is the replacement request. In this case, we are saying “When requested_directory is requested, get index.php instead.” And when we get index.php, we’re going to pass the requested file/directory as the value for the variable ‘page’. The requested file is the value of $0. It’s a recursive variable. Mod_rewrite rules adhere to regular expression syntax.

A request for http://www.foo.com/requested_directory/bar would be re-written to
http://www.foo.com/index.php?page=requested_directory/bar. Once the URL is rewritten, you can parse it like any other. Here, we’re going to require certain content files based on the value of $_GET['page'] using switch.

<?php

switch($_GET['page']){
   case 'requested_directory':
   require('../../req_dir_content.inc');
   break;

   case 'requested_directory/bar';
   require('../../bar_content.inc');
   break;

   default:
   require('../../default_content.inc');
}
?>

More information

• Apache 1.3
  URL Rewriting Guide

Simple, just type

> ls foo*

That will return all files that begin with foo, including foo.php,
foo_bar.php and foot.php.

Want to check the permissions on those files too? Type:

> ls -l foo*

I ran across an example of this today and it’s just a really bad practice. These files are web-readable, and by saving it as an .inc file, you are exposing your data to whoever stumbles across ‘db.inc’ or ‘globals.inc’.

If you must save files in your document root, save them with a .php extension (.php files are better, but at least one developer argues not by much.)

UPDATE: Ben Ramsey fills me in on the reasoning behind Chris Shiflett’s mandate.

There is a twofold reason Chris says that storing PHP includes within the Web root is not a good practice (there may be more than two reasons, but there are two that I know of):

1. your PHP scripts should never be accessed out of context, and leaving an include file within the Web root allows users to execute it out of context, potentially doing things you didn’t intend them to do, and
2. on the off-chance that the server crashes and reboots — but Apache doesn’t quite load PHP successfully — and it takes 30 minutes to an hour or more to get your hosting company to fix it, then all of your PHP files will be readable to the public as plain text, exposing your code and any passwords contained therein.

Both reasons are enough to convince me to place only those files that need to be accessed directly by the client in the Web root and all others above it.

Sound advice.

I confess I cheated a bit by hijacking the basic code from a Search Engine Watch article on creating RSS feeds.

But I still had to figure out how to automate the updating of the feed. Enter my old friend PHP and the magic Apache directive AddType.

I created a new directory (feeds), then created an .htaccess file in that directory with the following line: AddType application/x-httpd-php .xml. That lets the server know to parse X M L files in that directory as PHP files.

A few database calls later, and I’ve got a dynamically-generated RSS feed available for your pleasure.

You will need an aggregator, however. If you’re on a Windows box with Mozilla installed, I’d like to suggest Newsmonster. You’ll also need the latest version of Java.

Or try a service like Kinja

UPDATE: Now your browser will recognize it as an XML document, and your news reader will recognize it as a valid RSS feed. I had to modify the code a smidge, adding header("Content-type: text/xml"); to the script, stripping out HTML tags, and converting special characters.

MIME types are an interesting thing. They determine what types of content a server or mail application can handle.

The problem with using an XHTML MIME type is that most browsers do not support the type. Not surprising since there’s usually a few years’ lag between what the World Wide Web Consortium says and what the browsers do. The good news is that XHTML has backward-compatibility built in.

For more information about XHTML and MIME types, you can also read Mark Pilgrim’s article "The Road to XHTML 2.0: MIME Types"