Archive for the 'Flex Plugins' Category

24
Jun

Flex Rich Media Integration

Overview

Video and audio are fast becoming an important part of business and consumer applications. If you take a look around the Web today, you will notice the influx of Web sites that contain video and audio. You probably find the wrong version of the media player is installed or there are limited options to interact with the video. All of this disrupts the user experience, and this is where Flex and Flash are far more superior.

The Adobe Flash Player contains video and audio playback and streaming capabilities. As of this writing, Flash Player 8 is installed on 90 percent of users’ computers. This is the reason companies such as Brightcove, Google, and YouTube have adopted the Flash Player to play back video.

With Flex, video is more than just a streaming experience. It can be a more tightly integrated part of the application. During playback of video, events can be triggered and behaviors of other components are driven by the events, all of which creates a much richer experience. The capabilities enable an extensive range of new, innovative, and highly interactive applications. Continue reading ‘Flex Rich Media Integration’

12
Jun

Deployment Directory Structure

With the exception of the FDS2 deployment that was discussed earlier, the deployment of a Flex 2 application is very similar to Flash deployment. Flex Builder, by default, sets up a deployment directory that is used when debugging, although you can customize your deployment as you see fit. The only thing to keep in mind when customizing a deployment is that you must keep your pathing correct - meaning that, if you nest your XML files in an /xml folder for run-time parsing, you must ensure that your Flex application is pointing to that /xml folder. This applies to any external, nonembedded assets.

The following table shows a basic customized deployment directory structure.

Open table as spreadsheet

Directory/File Description
deploy/ The location of the root directory. Many developers choose a /source, /deploy directory structure, although you can use whatever you’d like.
/images The location of any nonembedded images such as PNG, JPG, and GIF.
/xml The location of any nonembedded, run-time-specific data that is wrapped in XML.
/swfs The location of any nonembedded SWFs used by your application.
/js The location of any JavaScript files.
myApp.swf Your application.
myApp.html Your application’s HTML wrapper.

Deployment with Flex Builder 2

If you are using Flex Builder 2 or the Flex Builder plugin for Eclipse, as mentioned before, both create a deployment directory for you. Located in your application project’s root directory is a /bin directory. This is where all of the wrappers are kept. The following table describes this structure.

Open table as spreadsheet

Directory/File Description
{appName}/bin/ Your application deployment root directory
AppName.swf The default SWF file for your application
AppName.html The default HTML wrapper for your application
AppName-debug.swf The default debugger SWF for your application that is used by the debugging version of Flash Player 9
AppName-debug.html The default HTML wrapper for your application’s debug file
history.htm The default wrapper for the history-management SWF
history.swf The history-management SWF
history.js The history-management JavaScript file
playerProductInstall.swf The Flash player detection/installation SWF for Express install

As you can see, by default, Flex Builder’s deployment isn’t very organized, but it works well for testing. However, if you’re going to use your own wrappers and directory structure with Flex Builder, keep in mind that you have to tell Flex Builder to not build out the wrappers by default, and redirect Flex Builder’s RUN and DEBUG commands to your custom wrappers.

Figure 18-9 illustrates how to disable HTML wrapper generation within the properties of your application. To do so, uncheck “Generate HTML wrapper file.”

12
Jun

Flex and Flash Player Security and Technology Concerns

Before jumping into a discussion of the design and development phases, it is important to consider how your Flex application will be viewed by the end users and how it affects security. Because your Flex application is compiled to a Flash SWF file and usually (though not in every case) deployed over a network, the majority of security concerns lie on the Flash Player itself. With this in mind, it is important to mention that there are ways to structure your data and work with the Flash Player that will help you create a more secure application. This section takes a look at network security concerns, open technology concerns, and what security features are available to you through the Flash Player.

Network Security Concerns

When building an Internet application in Flex (or any API, for that matter), network security shouldn’t be overlooked. Your goal is to keep sensitive data out of the public view. This may sound easy, because the average user would never be able to see how you’re loading data from XML or through AMF, but third-party tools have made eavesdropping easier for even your basic user. This is called a “man-in-the-middle attack.” The user is able to read and possibly modify data being sent from the server to the Flash Player client (in other words, your application). The following paragraphs discuss two common methods of reading data and their respecitive vulnerabilities.

You will more than likely use (or have used) XML to store data for a Flash or Flex application. Once it is up and running, it is a very convenient way to store groups of data that can be easily updated. However, XML is not a good place to store sensitive data, because XML is transferred over HTTP/SOAP and is encoded as Unicode or ASCII. This makes it immensely vulnerable.

Using your preferred browser, type in the URL to the location of your XML file (such as http://myserver/assets/myXML.xml). With any luck, your Web browser will display your XML, and some browsers will show you if your XML is malformed. If it didn’t display it immediately, but did load the XML file, go to View Image from book Source within the Web browser’s menu. If you can view your XML that is stored on the server, so can anyone else. You’d like to think most people would never try to look through your XML, but people are curious and sometimes malicious. Using a third-party program such as Sothink SWF Decompiler, someone could easily peek under the hood of your SWF and copy the URL to your XML. Even easier, someone could use a third-party HTTP header viewer such as the Tamper Data add-on for Mozilla Firefox to see what files are being requested. Such methods would give away the precise location of your XML file, allowing anyone to view its contents.

Flash Remoting and other remoting services that use Action Message Format (AMF) are a little more secure, but not a perfect solution. “Secure” is probably not the best term. Because AMF is a binary format, it is harder for the average user to view and interpret. Many developers, however, use middleware programs such as Charles by xk72 (http://www.xk72.com/charles/) or Service Capture by Kevin Langdon (http://kevinlangdon.com/serviceCapture/). Both programs act as a proxy between the server and the application. They parse data formatted in AMF and display it in their GUI. Such programs are convenient for developers, and are often lifesavers during the development process. But because the developer can view the data, so can anyone else who happens to be running these programs. Again, your average user probably is not running programs like these, but because they exist, you have to assume someone probably does.

So how do you avoid this? The safest route is to limit sensitive data altogether. If you are developing an application that requires large amounts of sensitive data to be passed to and from your application, it is recommended that you use encryption, such as Secure Socket Layer (SSL), through the browser. Using SSL encrypts the SWF file as well as data being sent over HTTPS, ensuring both the host and the client that their data is secured.

The other option for encryption is to use a cryptographic algorithm, such as MD5 or SHA-1. Flex does not natively support cryptographic encryption, but MD5 and SHA-1 libraries are available on Google Code as part of the AS3 Corelib, by Adobe (http://code.google.com/p/as3corelib/).

Open Technology Concerns

As with any open Web technology such as HTML and JavaScript, there is a certain degree of sacrifice that you must understand before deploying your application. Web applications that use server technologies, such as ASP, J2EE, or PHP, have an extra level of security that Flash lacks. When the user queries an application created in ASP or something similar, the server interprets the script and displays only the HTML necessary for the user to operate the application. The server hides all sensitive code from the user, and it is virtually impossible to view, unless you have the authorization to do so.

In the case of applications created in Flex or Flash and deployed as SWFs, clients download the application SWF directly onto their computers. This allows users complete access to your SWF, and it also allows them access to download any additional SWFs and supporting media that are called by your application. The redeeming part of using SWFs is that it takes third-party software to view your source, making it more difficult for most users.

Because your SWF is downloaded to the users’ machines, it is recommended that you rely on the server to validate sensitive information such as usernames and passwords. It is all right to check character length and integrity from within Flash, but as far as encryption and validation go, it’s better to store this on the server using a server-side technology, making it more difficult for people to gain access to that information.

Flash Player Security Features

As mentioned earlier in this section, Flash Player handles the bulk of the security for your Flex application.

Flash Player’s main mode of security is through sandboxes. A sandbox is a security grouping that limits the Flash Player’s access to certain resources. The following table describes the four types of sandboxes.

Open table as spreadsheet

Sandbox Description
Remote By default, when a user downloads an SWF from a Web site, it can only access SWFs within the parent domain, or domains specified within the Security.allowDomain() or crossdomain.xml file.
Local-with-filesystem This allows an SWF executed in Flash Player locally to access the local filesystem. However, because the SWF is not trusted, it cannot communicate over a network.
Local-with-networking This allows an SWF executed in Flash Player locally to access a designated Internet URL. However, because it’s not trusted by the user, it cannot read from the local filesystem.
Local-trusted The local-trusted sandbox allows users or administrators of a machine to place an SWF into the “trusted” sandbox. When an SWF is trusted, it can access data over the network and on a local machine. Again, this must be set by the user or the machine’s administrator.

Flash Player’s method of security is fairly straightforward. When users access a site that contains a Flex application, they are downloading the SWF onto their computer. At that point, Flash Player sets up a security sandbox that limits the data being sent and received to only media that is within the domain of origin. For example, if you, as the developer, would like to access and manipulate an external SWF from your application using <mx:SWFLoader>, you can do so if it fits the following criteria:

  • The SWF was created for Flash Player 9, meaning it is coded in ActionScript 3 and not ActionScript 2 or below.
  • The SWF is within the same domain as the parent SWF trying to access it. If your application is at the domain http://www.domainA.com/, it can access child SWFs contained within that domain (such as http://www.domainA.com/swfs/SWF_2.swf).

However, both rules can be broken. If you need to load legacy content, such as content created in Flash 8, you can use the LocalConnection class. If you need access to an SWF outside of your domain, you can grant access to it using Security.allowDomain() or by editing the cross-domain policy within the crossdomain.xml file.

Another security sandbox feature is that once an SWF is downloaded onto the user’s machine, it has limited access to the local hard drive. “Limited” means that it pretty much has no access whatsoever, except for data being stored in a SharedObject. A SharedObject is a file stored locally on the machine running the SWF that created it. It is available only to the parent SWF, or allowed SWFs within the sandbox boundary. As the developer, you can store client-specific data to the clients’ machines, but you are limited to only 100KB of space per domain. The shared object file itself is stored in a pseudo-random directory path in order to avoid outside tampering. See Chapter 8 for details on how to use shared objects.

Flash Player 9 offers garbage collection that clears the Player’s memory each time the Player is accessed. This will assure the developer that the memory is completely wiped clean so that no application will have access to data stored from prior sessions.

Lastly, Flash Player offers a time-out on procedures that are stuck in recursion loops. For example, if you have a for loop that continues to be executed, eventually the Player will acknowledge this process as potentially harmful, and will prompt the user either to break the execution of the script or allow it to continue. This is particularly useful in ensuring that an SWF cannot execute a denial-of-service attack.

24
May

flex Message Channels

Messages are transported to and from service destinations over message channels that are part of the Flex messaging system. You can take any service and pair it with any type of channel.

The channels that are supported are HTTP, AMF, and RMTP, and all of them can be used securely. The AMF and HTTP secure channels transport data using HTTP over Secure Socket Layer (HTTPS) and the RMTP secure channel uses RMTP over Transport Layer Security (TLS).

The following example is an AMF channel definition. Below the channel definition is a destination that references it.

 <destination id=”MyTopic”>
         <channels>
             <channel ref=”samples-amf”/>
         </channels> </destination>  <channel-definition id=”samples-amf”
         type=”mx.messaging.channels.AMFChannel”>
         <endpoint uri=”/myapp/messagebroker/amf” port=”8100″
             type=”flex.messaging.endpoints.AmfEndpoint”/> </channel-definition>

Channels can also be assigned on the client at run-time by using the ChannelSet object. This object contains one or more Channel objects.

 var channelSet:ChannelSet = new ChannelSet();
 var myChannel:Channel = new AMFChannel(”my-polling-channel”, endpointURL);
 channelSet.addChannel(myChannel);
 // Assign the ChannelSet object to the RemoteObject instance
 myRO.channelSet = channelSet;

You can add as many Channel objects to the ChannelSet as you like. The ChannelSet object will search through the list of channels to find one it can connect to successfully.

The endpointURL is a read-only property, and is calculated depending on the value of the uri property.

The process of connecting to a channel involves searching for the first channel and trying to connect. If this fails and the channel has failover URIs defined, it will try all of those before searching for the next available channel.

Data Serialization

This section describes the serialization to and from ActionScript objects on the client and Java objects on the server. It also contains information about serialization to and from ActionScript objects on the client and SOAP and XML schema types.

ActionScript-to-Java Conversion

When sending arguments from a Flex application to a Java object, the data is converted automatically from an ActionScript data type to a Java data type.

An ActionScript Array can be indexed in two ways: a strict Array (in which the indexes are Numbers), or an associative Array (which has at least one index that is a String). It is very important that you know which Array you are sending to the server, because the data type changes in the arguments when used to invoke the Java object method.

The following table shows simple data type conversions from ActionScript (AMF 3) to Java.

ActionScript Type (AMF 3)

Deserialization to Java

Supported Java Type Binding

Primitive values cannot be set to null in Java, and so Flex interprets null values as the default primitive types. Note that a Java Collection can contain any number of Object types, but a Java Array must be the same type.

Java-to-ActionScript Conversion

The following table shows simple data type conversions from Java to ActionScript (AMF 3).

Java Type

ActionScript Type (AMF 3)

You use the [RemoteClass(alias=”the.package.and.class.name”)] metadata tag to create an ActionScript object that maps directly to the Java object found on the remote server. The data converted to the relevant ActionScript class must be referenced or used in the MXML file. The typical way of casting the result object is shown in the following example:

 var result:MyCustomClass = MyCustomClass(event.result);

The following example shows you how to use the [RemoteClass(alias=”")] metadata tag:

 package com.mycompany.vo.User {      [RemoteClass(alias=”com.mycompany.vo.User”)]
      [Bindable]
      public class User      {           public var id:Number;
           public var username:String;
           public var password:String;
           public var emailaddress:String;
      } }

Note that you can use the [RemoteClass] metadata tag even if you do not have an alias or Java object to map to on the server, but you do send back a typed version from the server. If you send your typed ActionScript object to the server, it is serialized to a Map object. However, if the typed object on the server is sent back, it will be serialized to the original ActionScript type.

ActionScript to Schema and SOAP types

Sending SOAP requests using Flex requires that the information be appropriately represented in the corresponding ActionScript types. Complex types and SOAP-encoded Array types are supported.

The following table shows type mappings between SOAP types and ActionScript types.




 

September 2008
M T W T F S S
« Aug    
1234567
891011121314
15161718192021
22232425262728
2930  

Badge Farm

  • Textmate