Javascript and Cross Domain Scripting Solution From Mozilla

A friend recently passed a long an article found on slashdot regarding XSS, and for more information I visited the Mozilla Blog that discusses this concept in greater detail.  In an effort to save time I will summarize the articles as this, you will not be able to use in-line javascript, inline event handlers, or load javascript from unapproved domains.  Basically, you will need to have all your javascript loaded in external js files, and then create a policy that allows the js to be loaded by a domain. Now after reading these articles, and mulling the concept over for a few minutes, a few things came to mind.

The amount of legacy code that produces inline javascript, or inline event handlers, etc..

The amount of time to refactor this code, and I am referring to enterprise applications not your Mom’s blog.

A way to move developers towards unobtrusive javascript, i.e. adding event handlers through script and not putting them directly into the html markup.  This is a positive as markup is markup.

With this approach would the need for Javascript micro-architectures arise?  Think PureMVC and Cairongorm for Flex.  After all we are already using javascript application frameworks, shouldn’t we have some architectural frameworks for html/css/javascript clients?

Overall I am not to0 concerned with the implications of the concept presented by Mozilla.  I feel that in the end it will make developers realize that there are some fundamental shifts needed in the client side development arena that go beyond creating the next cool javascript widget or library.

XSS is a real threat and by attempting to solve this issue we may all have to create a better architecture for our clients.

Five Minute Flex Twitter Client

Yes, yet another Twitter client. Does the world really need another Twitter client? Probably not. But this particular client was created based on a challenge that was issued by a fellow developer. The challenge – create a Flex app that uses a social networking service, and has at least one custom component, all in five minutes or less.

Here is the source code download, go ahead and tool around with it: Flex 5 Miute Challenge Source Code
So go ahead and have some fun, get together with some developers and tryout the ‘Flex 5 Minute Challenge’

Since my buddy and I made this up we came up with these rules, feel free to change them:
Flex application must utilize any service provided by a publicly available social networking site.
The application must contain at least one custom component.
Time begins as soon as you start writing code and the app must be published as a release build before 5 minutes is up.

That’s it, it’s fun, give it a shot.

So here it is:
[kml_flashembed publishmethod="static" fversion="10.0.0" useexpressinstall="true" movie="" width="500" height="300" targetclass="flashmovie"]

Get Adobe Flash player


Flash Player and REST Issue Work Around

RESTful services, ah the thought of leveraging the HTTP protocal to make web service development much simpler than the ‘ole SOAP.  But there is a problem, if you are a Flex or Flash developer that relies on the Flash Player.  You see, staying true to the methodology and spirit of RESTful services means that an HTTP Status Code of 404 actually means something.  It means the resource that was requested was not found.  So in a RESTful service you may call a phone book service that returns a person and their phone number.  Well if that person does not exist the REST service returns an HTTP Status Code of a 404.  Get it? Got it? Okay.

The problem with REST and Flex/Flash is that the Flash player is not able to allow you to write code to handle a status code that falls out side of the 200 range.  If you receive any status code that is not in the 200 range then you receive a fault error.  “If I am calling a REST service and I get something other than a 200 then I can just treat it as a 404,” you say.  Not so fast, what if you get 500 range status code?  Hmm, now what?  Enter, Flex and Javascript together.

Leveraging Javascript with Flex can allow you to handle HTTP Status Codes without having to write server side proxies or having to beg the RESTful Developers to not use status codes as their request response.

Here is how the Javascript and Flex solution would work (here is the source code – JavascriptFlexStatusCodeSolution)

The idea is to use ExternalInterface in Flex to call a Javascript function.  The javascript function makes the call to the RESTful Service. When the response comes back we use javascript to check the status code and then call the appropriate Actionscript code in the SWF file.  Sounds simple?  It is, so download the code and check it out, and hopefully you can get past the status code pain.