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.
Wednesday, December 8, 2010
Friday, November 19, 2010
Cross Domain Policy file goodness!
What can I say? I am a little proud. Today I put out a long burning old flame. And no, I am not talking about ex-girlfriends. I am talking about security problems in regards to cross domain policy files, SWF security policies and hocus pocus mumbo jumbo.
Here was my scenario. Let's go back in time for 3 months and pretend its August...when I built our initial FLEX 4 application. I would mannually deploy the app to a web server. Let's say it was located at 172.0.0.1. We were really happy with how that worked, we can hit the server via a browser, login and get down to business. Everything was gravy. Too easy, mate! Or not?
Then we decided that using an IP address to access our web portal was not ideal. Sales guys no likey. So we decided we do not want to demo the application to customers using an IP address. It seemed a little un-professional. So we came up with a domain to use, like so: "http://portal.mycompany.com/".
We were hoping we were done at this stage and we could all go on some big tropical vacation, reaping the benefits of FLEX 4. We were wrong. Oh so wrong.
Using the new domain name, we could hit "portal.mycompany.com" SWF and get to the login page just fine. But when we try to actually login and authenticate, the application would just hang.
This was so frustrating as I was brand new to FLEX at the time. We logged it in our bug tracking system but have sat on it for a while. 3-4 months, respectively.
Fast forward 3 months. I have a little extra time on my hands now that I have some help sitting directly next to me. I revisited this "bug" yesterday and determined it wasn't really a hosting/re-directing issue with our hosting provider, although my original assumption was that it was. I had been reading up on FLEX previously and had read much about "cross domain policy" files, regarding domain security. I will eventually need to make use of this when we decide to convert to HTTPS and SSL, to secure our protocol. So in essence, I had already done some of my homework for this.
My co-worker pointed out that the "Flash Builder 4 and Flex 4 Bible" book has a section in "Chapter 23: Working with HTTPService and XML - page 746" that overviews Cross Domain policy issues. I have already read plenty on the subject on the web but could never figure out how to put this cross domain XML policy file into my application, or even create it. There is very little about that. There is much explanation on domain scenarios and the different quirks you may run into. But there is no good documentation anywhere on how to actually setup a cross domain policy file for your application. Or even in your application?
The book covers in great detail how to use the file, but doesnt really tell you how to create it. I noticed at the end of the chapter there tiny little note that says you should visit this link to read more on how to use this thing.
From what I gathered there, you need to generate the XML file manually.
It is important to point out that the crossdomain.xml file does not get added to your FLEX project at all. Instead, you place the XML file in the "root" of your web server directory, which for me was, C:\inetpub\wwwroot.
Originally I had tried to place the crossdomain.xml file in my publish folder, where my application and SWF file resides. This did not work!! It is ultra important that the XML file be placed correctly in the server root folder. Once I placed it there, everything worked fine and our long standing bug was marked resolved!!
Time to go eat some sushi at Whole Foods...Cheers!
Here was my scenario. Let's go back in time for 3 months and pretend its August...when I built our initial FLEX 4 application. I would mannually deploy the app to a web server. Let's say it was located at 172.0.0.1. We were really happy with how that worked, we can hit the server via a browser, login and get down to business. Everything was gravy. Too easy, mate! Or not?
Then we decided that using an IP address to access our web portal was not ideal. Sales guys no likey. So we decided we do not want to demo the application to customers using an IP address. It seemed a little un-professional. So we came up with a domain to use, like so: "http://portal.mycompany.com/".
We were hoping we were done at this stage and we could all go on some big tropical vacation, reaping the benefits of FLEX 4. We were wrong. Oh so wrong.
Using the new domain name, we could hit "portal.mycompany.com" SWF and get to the login page just fine. But when we try to actually login and authenticate, the application would just hang.
This was so frustrating as I was brand new to FLEX at the time. We logged it in our bug tracking system but have sat on it for a while. 3-4 months, respectively.
Fast forward 3 months. I have a little extra time on my hands now that I have some help sitting directly next to me. I revisited this "bug" yesterday and determined it wasn't really a hosting/re-directing issue with our hosting provider, although my original assumption was that it was. I had been reading up on FLEX previously and had read much about "cross domain policy" files, regarding domain security. I will eventually need to make use of this when we decide to convert to HTTPS and SSL, to secure our protocol. So in essence, I had already done some of my homework for this.
My co-worker pointed out that the "Flash Builder 4 and Flex 4 Bible" book has a section in "Chapter 23: Working with HTTPService and XML - page 746" that overviews Cross Domain policy issues. I have already read plenty on the subject on the web but could never figure out how to put this cross domain XML policy file into my application, or even create it. There is very little about that. There is much explanation on domain scenarios and the different quirks you may run into. But there is no good documentation anywhere on how to actually setup a cross domain policy file for your application. Or even in your application?
The book covers in great detail how to use the file, but doesnt really tell you how to create it. I noticed at the end of the chapter there tiny little note that says you should visit this link to read more on how to use this thing.
From what I gathered there, you need to generate the XML file manually.
It is important to point out that the crossdomain.xml file does not get added to your FLEX project at all. Instead, you place the XML file in the "root" of your web server directory, which for me was, C:\inetpub\wwwroot.
Originally I had tried to place the crossdomain.xml file in my publish folder, where my application and SWF file resides. This did not work!! It is ultra important that the XML file be placed correctly in the server root folder. Once I placed it there, everything worked fine and our long standing bug was marked resolved!!
Time to go eat some sushi at Whole Foods...Cheers!
Labels:
Cross Domain Policy File,
Domains,
FLEX 4,
Security,
Sub-Domains,
XML
Wednesday, November 17, 2010
FLEX 4 Framework Posters have arrived!
Today has been a rather hectic day. Many code changes, cool new component implementations and design discussions (not battles!). Amongst all this fun, I received a long awaited package, a tube rather, from my good friends over at Adobe.
I was expecting FLEX 3 posters. I was surprised when I opened the package to find FLEX 4 posters! AWESOME-O. I can finally see the entire framework shitcan in front of my face! I dont know if this will give me more nightmares or produce better code. Or both.
You can see the FLEX 4 framework posters here in action, on my wall:
(photo courtesy of my iPhone 4)
Alternatively, I suppose if you do not have an Adobe account or AdobeID, or if you're just completely psycho and Adobe obsessed, and wanted to print these out for your own personal collection of development posters at home, you could use these high-resolution .PDF versions of the posters from here.
^ ** If this link ever dies, just contact me and I will personally supply you with the .PDFs. And if you're extra nice, I wont even charge you for that!!
If you want the actual posters yourself, from your good friends at Adobe, then you must register for them here.
^ ** note: You must “update” your registration information first, but be sure to specify you want posters and NOT the lame online training. This is crucial.
You must login with your AdobeID. I forget if it needs the Flash Builder 4 serial number...(I do not think it does, but it may).
Cheers and happy FLEX postering....
I was expecting FLEX 3 posters. I was surprised when I opened the package to find FLEX 4 posters! AWESOME-O. I can finally see the entire framework shitcan in front of my face! I dont know if this will give me more nightmares or produce better code. Or both.
You can see the FLEX 4 framework posters here in action, on my wall:
(photo courtesy of my iPhone 4)
Alternatively, I suppose if you do not have an Adobe account or AdobeID, or if you're just completely psycho and Adobe obsessed, and wanted to print these out for your own personal collection of development posters at home, you could use these high-resolution .PDF versions of the posters from here.
^ ** If this link ever dies, just contact me and I will personally supply you with the .PDFs. And if you're extra nice, I wont even charge you for that!!
If you want the actual posters yourself, from your good friends at Adobe, then you must register for them here.
^ ** note: You must “update” your registration information first, but be sure to specify you want posters and NOT the lame online training. This is crucial.
You must login with your AdobeID. I forget if it needs the Flash Builder 4 serial number...(I do not think it does, but it may).
Cheers and happy FLEX postering....
Labels:
Flashbuilder 4,
FLEX 4,
Framework,
PDF,
Posters
Tuesday, November 16, 2010
FlashBuilder 4 - Text Editor - Annotations - ActionScript Occurrences
I normally customize any programming IDE I work in to use custom color coding scheme. I really really hate white backgrounds with black text, which is normally the default IDE colors for any IDE you choose to arm yourself with. I like to adjust my IDE's to colors that I prefer and can actually read for 40+ hours a week :)
In Flashbuilder 4, I have everything setup how I like it, except that I have one problem with self-highlighting syntax.
I noticed when I double clicked an object in Actionscript code, Flashbuilder 4 would highlight all matching references to that object. That's fine and great, but now that Ive changed my IDE color scheme to black, I could not figure out how to change the highlighting color.
It's really annoying and unreadable, look at it:
^ how annoying!
I asked around on the Adobe forum and finally received a response from an Adobe employee. He suggested I use:
Preferences > Editors > Text Editors > Annoations, "ActionScript Occurrences".
...it worked for me. I removed the "Text as: Highlight" and used "Dashed Box" instead. That's not as annoying and works much better! Thanks Jason @ Adobe...
In Flashbuilder 4, I have everything setup how I like it, except that I have one problem with self-highlighting syntax.
I noticed when I double clicked an object in Actionscript code, Flashbuilder 4 would highlight all matching references to that object. That's fine and great, but now that Ive changed my IDE color scheme to black, I could not figure out how to change the highlighting color.
It's really annoying and unreadable, look at it:
^ how annoying!
I asked around on the Adobe forum and finally received a response from an Adobe employee. He suggested I use:
Preferences > Editors > Text Editors > Annoations, "ActionScript Occurrences".
...it worked for me. I removed the "Text as: Highlight" and used "Dashed Box" instead. That's not as annoying and works much better! Thanks Jason @ Adobe...
Labels:
ActionScript,
Annotations,
Flashbuilder 4,
FLEX 4,
Text Editor
Wednesday, November 10, 2010
Does Adobe even use FLEX?
So I decided to be brave and ask the online Adobe community if Adobe even uses FLEX on their own website.
http://forums.adobe.com/message/3254067#3254067
**NOTE: I say it was brave because of the amount of animosity lurking over in the Adobe online forum community. Be sure to NEVER mention HTML5 or the impending doom of FLEX, in regards to HTML5. No matter whom you ask, you will get a biased answer and then be quickly told to shut up. I find HTML5 to be fascinating and it could shift the world of the internet into a different direction. Neither Microsoft nor Adobe folks seem to agree with what is going to happen there. So, just a word to the wise, dont mention it unless you're ready to have tomatoes thrown at you.
This question came about because of our frustration with Adobe's website, for various reasons. The main reason being that we had a hard time finding the version of FlashBuilder 4 to purchase a new license for. There are two different packages and my manager had a hard time navigating to it.
Jokingly, I pointed out that Adobe does not even have any FLASH or FLEX technology happening in their own website. That's a little concerning, since Adobe really pushes this stuff as being so great and wonderful.
So I asked the question on the Adobe FLEX forum and here was a response I received from an Adobe employee:
Last time I checked, photoshop.com and acrobat.com arent Adobe.com. I am sure there are "tons of intranet apps using FLEX" (as if we can validate that?) and I am sure there are tons of other great mysterious things happening inside Adobe headquarter doors we wont ever see. That doesn't really answer my original question though..."Does Adobe even use FLEX?".
Apparently, yes they do. Just not in public.
http://forums.adobe.com/message/3254067#3254067
**NOTE: I say it was brave because of the amount of animosity lurking over in the Adobe online forum community. Be sure to NEVER mention HTML5 or the impending doom of FLEX, in regards to HTML5. No matter whom you ask, you will get a biased answer and then be quickly told to shut up. I find HTML5 to be fascinating and it could shift the world of the internet into a different direction. Neither Microsoft nor Adobe folks seem to agree with what is going to happen there. So, just a word to the wise, dont mention it unless you're ready to have tomatoes thrown at you.
This question came about because of our frustration with Adobe's website, for various reasons. The main reason being that we had a hard time finding the version of FlashBuilder 4 to purchase a new license for. There are two different packages and my manager had a hard time navigating to it.
Jokingly, I pointed out that Adobe does not even have any FLASH or FLEX technology happening in their own website. That's a little concerning, since Adobe really pushes this stuff as being so great and wonderful.
So I asked the question on the Adobe FLEX forum and here was a response I received from an Adobe employee:
"Pretty sure the online apps on photoshop.com are Flex apps. Also acrobat.com.
And there are tons of intranet apps in Adobe which is the sweet spot for Flex."
Last time I checked, photoshop.com and acrobat.com arent Adobe.com. I am sure there are "tons of intranet apps using FLEX" (as if we can validate that?) and I am sure there are tons of other great mysterious things happening inside Adobe headquarter doors we wont ever see. That doesn't really answer my original question though..."Does Adobe even use FLEX?".
Apparently, yes they do. Just not in public.
Flash Builder 4 and Flex 4 Bible - HTML Template
"The book you need to succeed!!"
Today at work we had some discussion about scaling, scale mode and resizing FLEX applications in a browser. There are known bugs in this area, and browser compatibility issues. My coworker suggested I read the Adobe Flash Builder 4 and Flex 4 Bible, by David Gassner. Luckily I already had a .PDF copy and was able to bring it up on my computer screen, rather than thumb through a very large, 1000+ page book.
The section I covered was in Chapter 3: Building a Basic Flex Application. There is some good overview of the "html-template" folder and the html file that wraps the Flash Player/SWF file. It is within the html-template file that you can adjust the resizing/scale mode to handle different types of FlashPlayer sizing.
There is a bunch of Javascript in the html file that handles the FlashPlayer parameters, attributes and settings.
Also, within this html file and Javascript fun, you can set the "allowScriptAccess" property to be set to "never, always or sameDomain", to control outbound scripting capabilities from within Flash Player.
The Flashbuilder/FLEX 4 Bible book is a good start for any FLEX beginner. It is not my favorite FLEX book, but it has some good introduction to all areas of development in the FLEX realm. The big downside to this book is that it assumes you use BlazeDS, ColdFusion or Adobe specific server technologies. Since my entire backend is written in .NET, this book doesn't help me in the data access area.
Tuesday, November 9, 2010
Funny Flex quirk - Could not resolve mx:Component to a component implementation.
Subscribe to:
Posts (Atom)