Flex with REST Same Name Parameters, and SSL

Have a plane to catch, so figured if I blog when I have no time, I’d be brief for once in my life. Ready? Go.

Currently in Cali, awaiting for my flight to board back hom to ATL. Cali is 20 degrees colder than ATL; lame. 72 F (22 C) back to 91 F (32 C) will be a welcome change. I was here on-site with a client doing some consulting for my current contracting client. Confused yet? Don’t be, it’s fun. Figured I’d document the Flex lessons I learned while in the trenches the past 2 weeks.

First up, what do you do when a server-side developer gives you a REST API that has support for multiple parameters with each one have the same name? HTTPService won’t work as you think. HTTPService in a nutshell does a POST to some URL that supports parameters being sent to it in URL encoded variables. So, this:

var o = {};
o.name = “value”;
o.cheese = “muffin”;
o.skillz = “mad”;



HTTPService has 2 ways to give it stuff; either set it’s request property before sending or pass it in the send function. However, if a WebSevice accepts this:


Well… you’re kind of screwed. There is only 1 param…

var o = {};
o.param = “uno”;
o.param = “dos”; // overwrites uno
o.param = “tres”; // overwrites dos… all are same param variable

I tried my best to hack the IMessage object that’s associated with an HTTPService AsyncToken (mx.messaging.messages.HTTPServiceMessage I think), but no go. What to do? Uber l33t h@x of course!

1. At beginning of Cairngorm Delegate, store service URL property in member variable.
2. append your parameters manually the the server.url
3. var token = service.send();
4. in result / fault handles, set the service.url back to what it was

Works. Potential problem? If someone ELSE attempts to use that service, it’ll have that URL stored with it, with the URL encoded variables included. If your HTTPService is only ever used once, you’re good to go.

Second, SSL. SSL is not hard. I remember keeping that Ted Patrick SSL Flash / Flex entry bookmarked for the day a client would require Flash / Flex & SSL. I remember reading horror stories.

Those didn’t happen to me, though. I think in hindsight, every one’s problem was SWF security sandbox problems and NOT SSL problems. I remember reading about IE caching things, but either way, the ONLY thing that didn’t work was IE 7 on Vista because our security cert didn’t match up 100% with the real URL (we’re testing,hehe). Mac with Safari & Firefox, and PC XP with IE 6, IE 7, and Firefox all worked.

We’re not just talking about using HTTPS here for secure longins, we’re talking about:
– EVERY single request is HTTPS
– this includes file uploads
– the SWF is on the client’s website, but loaded from our webserver

That last part is the kicker. I learned that crossdomain.xml files have to explicitly allow ports, in this case 443. Dope!

Anyway, really rad to learn that if I ever develop widgets professionally, I can get SSL to work on said widget no matter where it is. I think the rule of embedding it with JavaScript with a relative path applies (like UFO or SWFObject); the SWF’ll think it’s loaded via HTTP, and go “Oh noes!!!”. Hardcode that mofo to https://blahblahblah.

Speaking of which, anyone know of any site like Akamai that supports SSL? Interested to hear how they handle it.

Finally, some cool links. talks about what I already know. Disagree about his points with regards to “if you don’t blog, you won’t get a good gig compared to someone who does” but the rest I do. If Expose and you raced, and you had this table as your computer screen, who wins? Finally, a video of Steve Jobs and Bill Gates getting interviewed together. Haven’t watched it myself but how can it not be cool?

4 Replies to “Flex with REST Same Name Parameters, and SSL”

  1. Yea… cough. SSL is a breeze when you dont have some nasty windows-based security firewall blocking (and attempting to proxy) all incoming SSL connections from outside websites (and by outside i mean as in outside our network backbone… so out of Atlanta).

    It’s been a mess the past 2 weeks with Jesse slackin on the beach in cali… erm i mean Jesse busting his ass to get this app working the way it was intended. It’s not a bug its a… feature!

    In all seriousness it’s amazing what can be done when your on site, its pretty miraculous we overcame the hurdles and completed the app for the client in the time alotted, not to mention we all had other projects we were working on in parallel.

    Good work JW.


  2. Hah, beach… dude, it was freezing in Cali. We’re not done yet, although, I think most of the remaining tasks are on my side. We’ll reconvene Monday.

  3. Can you elucidate me on the problems with embedding Flash with JavaScript? With the new security introduced with ActiveX, you HAVE to add SWFs with JavaScript now, or the user has to “activate” it by clicking on it first. I have a SWF running under SSL that loads another SWF from a relative URL. It works in FF, but Flash cancels the download (ClientAbortException on the server after serving between 32k and 49k of the file) in IE.

Comments are closed.