This happened twice in the last two days and for the second occurrence I totally forgot what the issue was the first time I fixed it. So the lesson is blogging about this stuff as it happens saves time regardless of deadlines.

So you're in Flash or Flex and your fileRef is failing to upload. Flash(Flex) Builder is telling you there's an IOError, but the line number given is where you set the local path of the File Reference. "WAHT!," you try an Event Listener and it does nothing. You vain atry/catch statement and it catches nothing. Despite what the compiler is telling you, you expand the try/catch statement to your whole uploading function hoping to narrow the issue down, but it does nothing. Finally you resort to Debugger breakpoints throughout the function and you discover it's actually being triggered by the call to fileRef.upload();. The possible causes just increased by an order of 50.

Before you break something in your office, you should know that File Reference IOErrors can be triggered by a failing server upload script. Now hold on, you'd think IOErrors would only happen if the upload script URL was wrong or broken, like if you missed a semicolon in your php or some silly thing like that. But thankfully Adobe went the mysterious route and made this as ambiguous as possible. There are a ton of reasons why your upload script might fail in such a way that it triggers this error in flex, or in a non-debug version of your app just stay stuck at 0%, and it might not be immediately apparent or fun to track down. Reading this now you are appropriately upset, but wait another second.

The first time this happened to me yesterday it happened because the upload name when I was getting the filesize of the temp upload file was wrong. In the following code that's the upfile1 part.

$filesize = filesize($_FILES['upfile1']['tmp_name']);

Then about 20 minutes later the same mysterious IOError popped up, but this time it was the server path I was moving the upload to. The path's are relative and I'm dyslexic, nuff said.

move_uploaded_file($_FILES['upfile1']['tmp_name'], $incorrect_relative_file_path)

Today however I was _shocked_ to find the crazy IOError because this time I knew all the paths were correct. In fact everything related to files was correct. I was sure, and I felt betrayed. (Once I re-realized that it wasn't a regular rational IOError... again). After a quickly unpleasant hunt through 1000+ lines of code I found a mysql query that was failing outside of an if/else clause. The reason it suddenly broke was that while editing the database at 5am this morning on no sleep I hit the wrong button -- so instead of deleting a column I accidentally dropped a whole table. There were two knew columns added since I backed it up that I had forgotten about in the haze, one of which caused the MySQL query to fail.

I collapsed asleep last night with this unsolved, I had nightmares that alluded to it. Really. But after 5 hours the frustration overwhelmed my capacity for dreaming and I leaped out of the surreal scene and into another one --Dreamweaver. Now knowing this had a solution and that I'm not gonna have to run through a field at night with a town's worth of pitchforked locals chasing me I feel expansive relief. Makes me wonder if I'm doing this to chase that feeling or if it's just a side affect.

You probably found this because you're trying to make a socket connection from Flex/Flash and getting the following error:

SecurityError: Error #2123: Security sandbox violation:

Adobe went through a number of phases making the rules for serving and checking Policyfiles stricter. There are different security sandboxes. If you publish your flex/flash application on domain.com, and the application attempts to load content from domain2.com, it will look for a Cross Domain Policy File at domain2.com/crossdomain.xml to get permission. It does this automatically, however you could specify the location of the Cross Domain Policy File in your flex application using the following method:

Security.loadPolicyFile("http://domain.com/remote_content/crossdomain.xml")

A Cross Domain Policy File only has authority to grant access to content below it in the folder hierarchy. So a policy file in /remote_content/ can't grant access to content in the root folder, and in addition a Policy File at the domain root can override any other policy file. It has maximal authority. Subdomains are considered separate domains - which as a side note most search engines see subdomains that way too.

Now that's Cross Domain Policy Files, In general Adobe Air applications operate in one of the local system sandboxes and has thus have access to content on any domain. This post is about Socket Policy Files. When you access regular web content you're generally connecting to your server on port 80 and being served content by Apache or whatever web server you happen to be running. When you do this you're using http protocols under the hood and never have to deal directly with that crazy stuff. If you want to make a raw socket connection to your server you will need to serve up a Socket Policy File on a specific port.

First I just want to stress the difference between a Cross Domain Policy File and a Socket Policy File. For some reason my dyslexia and the ton of misleading, vague, and now out of date and incorrect information I kept thinking they were the same thing. Second there is no way as far as I'm aware to serve a Socket Policy File with Apache.

The default port for flex/flash to search for a socket policy file on port 843. There are several places on the web that talk about being able to connect to higher port numbers without a Socket Policy File, well that doesn't seem to be the case anymore. Just assume that any raw socket connection from a flex/flash client requires a Socket Policy File.

You can serve the Socket Policy File from the port you're connecting to, but this is tricky considering the manner in which Flex/Flash goes about loading the Socket Policy File and rewriting the service to serve this up, especially if you're using server software built by someone else, means it's just better to keep the Socket Policy File Server as a separate always running entity on the system.

Now in the simplest implementations you need a process either written in python, perl, c++, php cli, or whatever. It needs to be listening on port 843. It has to wait for - very specifically - the following string<policy-file-request/> followed by a NULL byte. Upon receiving that it needs to serve up the policy file which needs to at least have allow-access-from domain set to *, and to-ports set to *. You should use the links at the end of this post to familiarize yourself with the differences between and all options you can specify in Policy Files. It's easiest to keep the Policy File as an actual file, instead of adding the text of the file to your custom server code. And that's it!, now you can go on with a better idea of what information out there is out of date or not.

Here are some important links to help you on your journey:

Adobe on setting up a Socket Policy File Server

Adobe on Policy File changes for flash 9 and 10

Adobe on the structure of Policy Files

An intro to Sockets

Working PHP Cli Socket Policy File Server

First of all GRRRRRR!!

Second, this has been one of those things I randomly get sucked into between projects where I'll spend 5 hours on Google trying to figure it out and getting tiny fragments of info but never actually solving the issue. This is the worst! What the hell am I talking about? Say you use MAMP or whatever as a local testing server. You write some PHP and you need to use the mail() function. You test your new email function to your personal gmail account. Ok so you try it and it doesn't work, or even worse it works a couple times and then never again.  So you go to Applications->Utilities and fire up the Console application. You're shocked to see that there's a message in there saying something about Gmail not accepting mail from your IP address because it's registered as a residential thingy and apparently a lot of spammers use their personal computers to send spam.

So you say no no there must be some mistake I'm a programmer, not a spammer, I'm just trying to test out my new app. But you quickly realize you're talking to a computer, pleading, and well it doesn't care. typical. After, you cry and try piece together a coherent step by step set of instructions to route all mail sent from your computer through your Gmail account - so it would be from you, and all go through. here's what you do.

note that $ is used to show a new terminal command, you don't actually type it in:

Open Terminal - found in Applications->Utilities and type in:

$ sudo nano /etc/postfix/relay_password

You'll now be editing a new file called relay_password in the nano Terminal editor, type in the following substituting your login info - it should work with google apps accounts as well:

smtp.gmail.com example@yourdomain.com:yourpassword

Press ctrl+o on your keyboard followed by Enter to save the file, then press ctrl+x to exit the editor.

Now type in:

$ sudo postmap /etc/postfix/relay_password

That should tell Postfix to use the relay file you just created. Gmail uses a secure connection so you need to head over to Verisign and download some root certificates. Go to the following url fill out your info and download the .zip file:

https://www.verisign.com/support/roots.html.

Now type in the following commands one after another. In the second command it wants the roots.zip you just downloaded, you can just drag the zip file onto the Terminal window and it will fill in it's location, don't do that for the 4th command though. Also note you may have some certificates already on your system, so after the second last command you may be prompted to replace existing certificates, type N so it doesn't replace the ones you have:

$ sudo mkdir /etc/postfix/certs
$ sudo cp roots.zip /etc/postfix/certs
$ cd /etc/postfix/certs/
$ sudo unzip -j roots.zip
$ sudo openssl x509 -inform der -in thawte\ Primary\ Root\ CA\ -\ G2_ECC.cer -out thawte\ Primary\ Root\ CA\ -\ G2_ECC.pem
$ sudo c_rehash /etc/postfix/certs

Now type in:

$ sudo nano /etc/postfix/main.cf

Go to the end of the document, you can delete the MAMP stuff, also note that if you have MAMP Pro and you edit postfix settings from there it'll fuck up what we're doing here. So remember this going into the future and don't do that.

Paste in the following at the end of the document - note: use the keyboard to get around the document, but use the mouse to right click and paste:

relayhost = smtp.gmail.com:587
# auth
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/relay_password
smtp_sasl_security_options = noanonymous

# tls
smtp_tls_security_level = may
smtp_tls_CApath = /etc/postfix/certs
smtp_tls_session_cache_database = btree:/etc/postfix/smtp_scache
smtp_tls_session_cache_timeout = 3600s
smtp_tls_loglevel = 1
tls_random_source = dev:/dev/urandom

Save it like we did before by pressing ctrl+o, then Enter, then ctrl+x.

Now type in:

$ sudo nano /etc/postfix/master.cf

You're now editing master.cf, this is a different file to main.cf we just pasted stuff into. There should be a table in here, find the line in the table that looks something like this:

#tlsmgr    fifo  -       -       n       -       1       tlsmgr

Make it look like this - note the comment is removed and fifo should be unix:

tlsmgr    unix  -       -       n       -       1       tlsmgr

Save it like the other times pressing ctrl+o, then Enter, then ctrl+x.

Ok, so at this point you can put the following into terminal and see that it works - put your email address in there twice:

printf "Subject: blah" | sendmail -f user@gmail.com user@gmail.com

Postfix is working now. good. You go back to your PHP application and test the mail()function again. If it works then you're done, but if not you panic. You start feeling really hungry. You know that Postfix is working but maybe PHP or Apache haven't gotten the message yet. ok. So you see in Console that sendmail is crashing, you open the crash report in Terminal and it tells you there's an incompatible version of libxml. It wants 10 and you have 9. You begin questioning if any of this is worth it and maybe you should just go sit in front of a tv and forget about doing anything meaningful with the rest of your life.

After almost installing XCode and registering as an apple developer so you can make and install the newest version of libxml, you wonder if maybe MAMP comes with libxml and find that yes it does. So instead of spending 2 hours upgrading the system libxml only to find it doesn't do anything you just upgrade to the latest version of MAMP (1.8 at the time of writing) and it works. What?? it works? really? yup. so what do you do now?

REJOICE! with lunch.

Some of this was scoured from random forums and blogs in the midst of complete frustration and combined into steps that actually work. A chunk however was taken from this post: http://dejan.ranisavljevic.com/2009/05/28/enable-postfix-with-relay-outbound-to-your-gmail-account-on-os-x-leopard/ so check them out.

If you have Adobe CS, Flex Builder, Flash Builder or otherwise use the Debuggerversion of Flash Player you quickly realize that a lot of sites out there don't bother with error handling in their apps and widgets.  This sucks because everywhere you go you get these error messages and all you can do is click them away and contact the developers, who if they cared would have dealt with the errors in the first place.

You can easily disable these error messages and then just re-enable them when you're debugging something. So here's how to do that:

1. Find or create a file called mm.cfg in the following folder:
   OS X: /Library/Application Support/Macromedia
   Win XP: C:\Documents and Settings\username
   Win Vista: C:\Users\username
   Linux: /home/username
2. Add the following line to the file and save it:
   SuppressDebuggerExceptionDialogs=1
3. That's it, to turn debugging back on change that value to 0