In reading over the Adobe AIR 1.5.2 Release Notes, the most noticeable change for end-users seems to be a friendlier install screen for signed apps.
The AIR application installer panel that displays the publisher identity has been simplified when an application is signed with a chained certificate
Sure enough, it is a much more welcoming experience as can be seen from the screenshots below:
Previous to AIR 1.5.2
Mmmmm… much better!
There are also a few API changes that developers should take note of including a favorite of mine- the ability to intercept an ESC key in fullscreen interactive mode. A bunch of other cool stuff and many, many bugfixes are included.
Get Adobe AIR 1.5.2
Adobe AIR 1.5.2 Release Notes
After having deployed many AIR apps with self-signed certificates over the past year or so, when I finally got one from a certificate authority I was quite happy to update my apps with it. Not so fast! You can’t update an AIR app that has been signed with a different certificate than a previously installed signature. It will cause AIR to throw an installation error.
This will be my attempt to document the steps taken to get the certificate migration to function correctly. I’m using Flex Builder 3 on Windows Vista.
In many of my AIR apps, I use the AIR Update Framework which allows an app to check for updates to itself. Anytime a user would try and auto-update or even download and install an updated .air file manually (without first performing an uninstall), they would receive a generic installation error. That’s no good.
My first inclination was to place a warning in the updater XML file letting users know to UNINSTALL the app- then REINSTALL because of the cert change. Not very graceful and the update notes are collapsed by default anyway- no one would see them. That’s when I began searching and found this in the LiveDocs:
It tells you a lot but fell a few points short for me. ADT (AIR Development Toolkit) was referenced- was this included in the FB3 SDKs or was this an additional download? Where do I find it?
After a bit of digging around, I located it in “C:\Program Files (x86)\Adobe\Flex Builder 3\sdks\3.2.0\bin”. To get it to work properly though, one should set up an environment variable in Windows. On Vista, this is done by going to System Properties, clicking Advanced System Settings, and pressing the “Environment Variables” button. You’ll want to look for the “Path” variable under “System Variables” and append the location of ADT to this. Be sure to separate each Path value item with a semi-colon.
The proper syntax for performing a certificate migration is “adt –migrate -storetype pkcs12 -keystore cert.p12 myApp.air myApp.air”. So I opened up a command prompt, navigated to the application directory and punched in my command. No good. ADT spit back an error that it couldn’t locate ‘java’. I know that Java is running on my system- so on a hunch, I added another environment variable to point to my Java installation folder- “C:\Program Files (x86)\Java\jre6\bin”.
Running ADT again and I was prompted for my certificate key and upon entering that, ADT was able to successfully migrate my cert!
I had posted earlier concerning a strange issue with Flash Player 10 where the SWF would refuse to load if being served over a Java servlet. We’ve been able to resolve the issue by explicitly transferring any SWF content with a “Content-Disposition” header of “inline” as suggested by Adobe. The relevant portion of this document is replicated below:
Starting with version 10,0,2, if Flash Player sees a “Content-Disposition: attachment” header while downloading a SWF file, it will ignore the SWF file rather than play it. Note that this restriction applies only to SWF files and not to other types of content, such as images, sounds, text, or XML files, policy files, etc.
If you control the HTTP server on which the SWF file resides, determine whether you trust the SWF file to execute in the server’s domain. If so, remove the “Content-Disposition: attachment” header by changing your HTTP server’s configuration.
While our resolution did differ slightly from the one posted above. It effectively does the same thing.
I had heard about a security concern over Amazon’s video streaming service a few days ago with a lot of people (including some at Amazon) blaming Adobe for the security hole. Apparently, there is an exploit in their (Amazons) player that allows stream-ripping a full video.
I’ve read the documentation on FMS3 security features and have used quite a few myself. Knowing these features, I could not understand how the Flash Player security model could be at fault- it seemed much more likely that the developers simply didn’t cover all their bases.
Whenever I read something like this, I am naturally concerned as I’ve thrown quite a bit of support behind FMS over the years.
Well, it seems that my hunch was correct and Adobe is not to blame. People are far too quick to pass judgement on things like this, whether it’s Adobe, Microsoft, Apple or some other giant corporation, everyone jumps on the bandwagon when a story like this breaks. Give it a rest…
I’m working on a way to proxy stream data from Flash Media Server to client applications on separate domains. There should be a simple mechanism in place to take care of such security restrictions, but since there is not, my plan is to create a proxy SWF that lives on the same domain as FMS and deals with the collection of BitmapData and ByteArray object data which is then able to be accessed by the parent SWF.
Not sure if this will work or if the security sandbox prevents access to RTMP data unconditionally. I know this method has been used for simple cross-domain data transfers over HTTP with success. This may be something different alltogether as a security policy file doesn’t mean “boo” in regard to RTMP streams. More documentation on these security restrictions and more news on the features of FMS3 would help.