Highly flexible applications and highly secure applications are usually at the opposite ends of the spectrum and require some sort of constant balance. So how do you mitigate your security risks when you need to build an application that is dependent on running modules at runtime via some sort of configuration?

ApplicationDomain.currentDomain is the just about the worst thing you can do when trying to build a secure application.

The problem:
Your modules are loaded at runtime which need to interface internal code you’ve written in your main application. This means the ModuleLoader needs to then set the currentDomain to ApplicationDomain.currentDomain. However ideally the module loader needs to be able to distinguish levels of trust if it’s a module you (or trusted developer) have written, or a rogue module.

The ugly issue:
When using a blanket statement to allow all modules to load with the currentDomain, you are giving every loaded swf trusted access to your entire platform. Some cases, this isn’t a big deal. It becomes a nasty headache if you’re building an e-comm solution. It will allow man-in-the-middle attacks to allow someone to load their module, and using any number of methods for decompiling and introspection to figure out what class and methods are used to capture and/or listen to events for sensitive information like user info and payment tokens. Their swf only needs to add itself as an IEventDispatcher or through the document tree to add itself to the sensitive classes and wait for these methods to be triggered.

The solutions:
There are several different ways to help combat this problem, however some are better than others. Any solution pretty much involves using 2 ModuleLoader’s. One for secure / trusted, another for insecure untrusted. Always start the loading process from the insecure, then based on which method you choose -transfer the loaded swf to the untrusted ModuleLoader via addChild(), swapChild(), etc.

  1. Use a trusted Interface in your platform that is always loaded at the application layer. However this is the weakest of them all since this only provides a minimal level of security as it can still be broken. The most flexible Modules use -load-externs as a compiler command to allow most of the dependent classes to be front loaded to the application. This makes things a bit speedier especially when loading several modules that share an entire platform. By using an internal interface you can check at the ModuleLoader level if the loading module has sufficient trust to be given access. This works in theory since the Flash AVM will not replace a duplicate namespace collision, but can still be defeated since I can write a rogue module and duplicate the secure interface using the exact same package.
  2. Use server side methods to generate hash key’s in the configuration which matches the particular node of the module in question. NEVER use this method in conjunction with deciphering the hash key internally, it’s way too easy to figure out what’s going on in your code. Instead pass this hash key back to the server, ask it to validate it against the file name and it’s own interally identifiable metrics (eg file size, mod date, etc) to then pass back a Boolean pass/fail for trust. Based on this service, then assign which domain it can be loaded into.
  3. Use a domain trust method in a static and final class to determine if the source of the module’s URL is coming from a place that is trusted. This basically means using RegEx along with hardcoded strings to determine if the URL is from ‘mydomain.com’. While this can be a bit laborious since it might require constant care to edit the domains that are trusted, however this particular solution isn’t as easily defeated since the list of trusted domains are embedded in your application.

The design detail:
You want to be able to create item renderers in a list that apply different styles depending on different visual cues or the data itself. For example lets take the TSA’s security approach with colors – the text changes for each level of severity.

The problem:
The problem is in handling the default case where every item renderer style should be the same, in the protected method of makeRowsAndColumns():Point After the itemrenderer instance has been created it’s styleName is set to the listContent container. This is important because no amount of setting through the ClassFactory properties, or setting styles anywhere in the pre-construction phase will save these unique values since it’s reset after it’s created.

The solution:
The one I came up with overrides the actual styleName property itself, where with a bit of checking we can safely ignore only the request coming from this creation area. This looks to make sure the object requesting the new stylename reference isn’t a ListContentBaseHolder or List so long as there is a stylename already set. Remember – properties are populated immediately after construction and before the initialization phase, that means this styleName will have already had something set on it from our ClassFactory in the List/Tree instance when setting our renderer.

override public function set styleName(value:Object):void
if (!super.styleName || (!(value is ListBaseContentHolder) && !(value is ListBase))) super.styleName = value;

Now in the List/Tree instance we can set our styleName:

<mx:Tree itemRenderer=”{myRendererFactory}” />
private function get myRendererFactory():IFactory
var cf:ClassFactory = new ClassFactory(MyRenderer);
cf.properties = {styleName:myStyleName};
return cf;

Not sure if anyone else has come across this, although I heard through someone else that it may have been mentioned by Grant Skinner on one of his circuits but I don’t see anything on his site about it.

As far as I know, this predominantly applies to applications built in the Halo space, although I suppose it could have some sort of implied effect to Spark.

The Symptoms: When setting the compatibility flag to “3″ certain runtime elements will render to the screen approximately twice as fast when using the Flex 4 SDK (and yes I mocked out an uber-simple PerformanceMonitor which checks the time delta between construction and the FlexEvent.CREATION_COMPLETE). This will become even more evident if you use a distributed rendering model to draw A LOT of elements to the screen (eg iterating a list of elements in a Queue paradigm -this is typically used to manage user expectations during heavy cpu cycles).

The Probable Cause: If you delve into the guts of SDK you’ll notice they use the FlexVersion.VERSION_3_0 just about everywhere in order to determine what behaviors or styles to run. It’s 1 way to keep your software platform up to date using a single source, however it complicates things with backward compatibility. The one area where it probably has the biggest affect is in the StyleManager. Considering the StyleManager is essentially a giant hash map used to manage both inherited, non-inherited, single overridden class selectors, and default type selectors: this is probably the biggest culprit for the Flash Player to be putting on the breaks.

The Risk Assessment: Thankfully not a whole lot appears to change and / or render incorrectly when using both a mix of type and class selectors in stylesheets. The one thing I did notice is some elements which would be typically interpreted as straight string must be encapsulated in quotes (eg textAlign : right now needs to be textAlign : ‘right’ ).

The Key: The key to using the flag is setting it to only 3 or 3.0, because this code checks against a Number, setting the flag to 3.1, 3.2, or 3.3 will cause the additional code to execute thereby giving you the same performance degradation as with just running the actual Flex 4 SDK.

I found only a few references to this, but not much of a well documented solution, so for those who stumble upon this needing one, you’re in luck.

The problem: The ComboBox does not dispatch a change event under all circumstances, most notably when you use the keyboard to select find the particular item in the list. Think of a states combo, where by ‘n’ will first cycle to Nebraska. This then closes the combo, but does not appropriately fire the change event as it would if you manually scrolled and selected ‘Nebraska’ from the list.

Why the problem exists: The combo is a composition of a TextInput, a Button, and a List. While the appropriate change event listener is added to the input, it’s not added to the List to it’s fullest extent. It only checks to see if non-printing characters are used to see if the user is attempting to scroll the list with the arrow or page-up / page-down keys. Thus, when using a normal alpha-numeric filter,¬† this doesn’t reflect itself in the parent combo control.

The fix: This fix is unusually difficult in light of the fact of one of my earlier rants that at best all properties and / or methods of a highly public and distributed platform, ie the SDK should only ever be protected. Literally all accessors to both the instance list and it’s combo listeners are private? What the hell?

Further proof of their own exacerbation, is a comment that literally says starting around Line 1512:

private function displayDropdown(show:Boolean, trigger:Event = null):void

// Subclasses may extend to do pre-processing
// before the dropdown is displayed
// or override to implement special display behavior

So remind me, how is that possible with a private selector? Oh yeah.

So the only way around this is to override the downArrowButton_buttonDownHandler() handler, and use the mx_internal::isShowingDropdown property to find if the list is about to be shown, and get a reference to the list by grabbing the dropdown property where you will attach your own ListEvent.CHANGE listener. In this handler you proxy dispatch a clone from the ComboBox point of view, and you finally have a change event that now works.

Finally, create another Event.REMOVED_FROM_STAGE event in the createChildren() method, since destroyDropdown() is also private (note to self: !#$#@!) to clean up your additional change event to prevent  a memory leak.

The problem domain: An issue exists where in a modular application you want to be able to share events from different modules without creating a dependency between the two. Deeply nested objects make this even more apparent when you realize you can’t use bubbling since they don’t reside within the same branch line down to the root trunk.


I’m putting this out there as a give back to other Flash-Flex developers that want to use Joomla! as a data repository for any projects, in part because Rune Skjoldborg Madsen has taken the time to build specific component views in php to change the transport layer to XML.


For anyone who might have noticed, especially if you’re coming from the flex showcase, the FlexPress application has been put in a suspended state of “permanent maintenance”. There are several reasons for this:

  • The xml-rpc.php gateway (at least as of version 2.4) had to behackedin order to inject additional methods to retrieve standard queries based on predominantly consumer-based methods. If you check the downloads section, it included things like getting data for blogrolls, comments, and a list of posts -where you only want the id’s and intro (useful for high volume). However because it was ‘hacked’ it made it impossible to keep up with the latest install. Since my php skills are elementary at best, it worked for the time being but it definitely had a short shelf life -if I put some time into it (read: not likely with home life), I could probably figure out how to extend the IXR gateway class to inject my own dependencies. With a recent update to 2.8 to eliminate annoying comment spam, this obviously broke the gateway, but broke it even further since I relied on SQL queries to get some of this data directly from the tables -however the tables have completely changed.
  • I’m at a point where I need to start giving serious consideration to updating the ‘portfolio’ side of things, however I’ve put it off as long as possible because while design-wise it still fits with the presentation I want, the management of data is gnarly at best. It was designed/developed with Dreamweaver, but as completely static html using templates -good at the time but considering the maturity of app services using any sort of DB, it finally makes it possible to do things that couldn’t be achieved with static content: popular views, most current views, segregation of recent projects vs. archived material, etc. Using Joomla -I decided on this primarily for the extensive plugin library that makes it possible to build not only a front-end layer (by getting to just the raw data -see my other post about this -for anyone who wants to do the same thing but with traditional fixed property classes) but also in a TeamSite-ish way, this is where I’ll be concentrating my efforts (when I have them) for the time being.

Since the portfolio would be a 2nd ‘mini’ app I would be building (in Flex of course), it gave me an idea to build an overall Portal application that can load and interact with Portlet modules -this of course being an excellent example of some of more indepth things you can do with Flex (especially if one builds cross gateway functionality -ie Mash-Up to either add/modify or implement interactive services from one portlet to another). One of the neat things that makes it possible in building modular applications, is if one was adventurous enough, could event build a second UI layer to manage the administration of the back-end functionality. Initial Portlets that will eventually be built:

  • The Portfolio (and Archive) with it’s Joomla back-end.
  • The FlexPress with a WordPress bank-end will be resurrected -most if not all of the UI will be re-incorporated but obviously the entire data services layer will probably have to be updated in a meaningful way.
  • A Gallery: this won’t be open to the public since it’s the media management center for our family -but I’ll screenshot it as a app in the portfolio.

I don’t make any promises of it’s current status since it’s very much still an development release (read: expect an occasional crash, plain ‘halo’ styles, and some parts just aren’t implemented yet) -but if you’re curious to see how this is turning out, you can check it here.

If you’re in a situation where you want to develop a project with SVN capabilities but don’t want to shell out several hundred a year for a managed host-server, but don’t want to open it up to host it on Google, an alternative does exist for the rest of us (this works especially well if it’s a single developer environment).

Tortoise has the capability to create local repositories, and it works even across networked devices like a NAS box.

To start your own it’s pretty straight forward:

Create a folder to hold the DB by selecting “Create Repository Here”:

Create a folder to hold the DB by selecting "Create Repository Here"

From your Project directory, select SVN Checkout.
The key here in selecting a local repository, is to use the file:/// protocol whether or not your drive is mapped or not.

From your project directory, select "SVN Checkout"

Add the following folders and you’ve got a traditional SVN repo that works: trunk, branches, tags.


It’s interesting to see, not necessarily from a backward compatibility model, but interesting none the less for those of us who are leading enterprise applications which are still stuck at “lowest common denomenator” just due to their tremendous size and expected reach.

I can certainly see how many applications can expect to reach a better performance vs cost (engineering man hours, legacy patch costs, etc) ratio for their intensive parts which either have the best chance for memory or cpu utilization management. Lets face it, none of our applications can be so brazen to run on a Cray with unlimited resources (although it sure as hell would be a lot easier on reducing Engineering constraints or getting “Pixel Nazi’s” off our backs).

This one seems weird to be but I guess I didn’t notice it earlier. As we all know Styles set as an external source need to be compiled first, which even for a modest application pushes this up to about 100k or so. I thought this was a bit heavy but didn’t think of it any further.

What the documentation tells you about Modules fails to mention that you can most certainly do the same thing when running the compiler on your compiled.swf stylesheet.

Run the stylesheet builder with the


against the

-link-report =report.xml

and instantly save at least 10x the file size (at least this is what I experienced), as it went down to about 10-12k or so.

mxmlc -link-report=myapplication.xml -output=myapplication.swf MyApplication.mxml

mxmlc -output=mystylesheet.swf -load-externs=myapplication.xml MyStyleSheet.css

Instant savings.

« Previous PageNext Page »