Wednesday, December 8, 2010

What?!?! You want to catch IO Errors? Not so fast there...

So I ran into a strange one (quirk). I was implementing some configuration for my web services. Apparently having a project level config file is not good enough. Why? Well, that's beyond my understanding. But it was my requirement to externally configure my FLEX 4 application to use an XML config file for webservice URL settings.

The idea is that I could change the config file to alter the webservice URL, regardless of the application build version. This way I can produce my application builds (manually at the moment) and place them on different servers, each with different webservice config files (dataaccess URLs). This way I do not need to alter any code to produce a build for each server. Kinda nifty. At the moment.

Once I finished spending my half day implementing these changes, I ran into some problems in regards to .SWF security and file access. When I ran my project locally with my debugger attached, everything worked fine. I could place the webservice config file ANYWHERE on my local machine and my FLEX 4 application was happy reading it.

But once I deployed the project to the server, and tried to use it, it was no longer happy. It was throwing exceptions. More specifically, IoError exceptions. My try/catch blocks were not handling my error at all, and I noticed the error type was different from what I was trying to handle. My co-worker suggested using "Error:*" as the object type, which would (in theory) cover all error types. This is valid FLEX wildcard syntax, believe it or not. (Nothing surprises me anymore in FLEX haha). Anyways, I redeployed my changes only to find out I still was receiving the exception. Very strange. So I went ahead and changed the error handler to use the error type "IOError", which was the type being displayed in the exception message in my browser. I was a genius.

So I redeployed this fix and was ready to cash in my trust fund billions and go to the Bahamas with a bunch of hookers to celebrate my stardom and new found celebrity status. WRONG. I still received the same damn exception, even though I explicitly handled it to redirect my browser, which was obviously not happening.

After doing some digging on google, I found out that a Flash has some security "features". I say "features" because they are not well documented and are questionable as to whether they're annoyances rather than "features" but I'll save that for another blogpost. The .SWF file is unable to access local files outside of it's sandbox, UNLESS it uses a URL. So if I wanted to access a config file outside of the application sandbox essentially I would need to hardcode a URL in my source code to point to the config file. HELLO, MCFLY, THIS COMPLETELY DEFEATS THE PURPOSE OF HAVING EXTERNAL DYNAMIC CONFIGURATION!!

Hardcoded URLs? Say it isn't so...so the fix was to put the config file into the application's sandbox, and reference it locally as so. This happened to work, quite well. The downside is the file is not contained in my project (yet), and the project is completely dependent on it. Plus, when deploying a build, I may accidentally delete this file when manually copying over the new build files. I have to consciously use my noggin to stop myself from the insanity of deleting config files on accident. Extra brain work. My brain is not happy about this.



^ Here you can see my magic IOErrorEvent handler being attached to the URLLoader object. For some reason, the try/catch stuff did not trap my error. But the event handler for this did. It became my friend instantly. Hopefully this can help someone, somewhere, at some time in the near or distant future or past. Well, definitely not the past.

No comments: