codeghost

UNABLE TO DEBUG FLEX FOR ANDROID 4.2.2

My Nexus 7 recently got upgraded to Android 4.2.2 and immediately Flash Builder started reporting that the device was not connected and that the Air runtime was not installed on the device.

The problem has been caused by the introduction of a gatekeeper on the phone, where when debugging a native Android app you have to accept an RSA fingerprint associated with your computer, presented on the device before your session will connect.

Adobe are looking into releasing a fix according to their forums, but in the mean time you can fix this yourself.

1. Download the latest version of the Android SDK and associated tools. You can use the Android SDK Manager to do this for you.

2. Navigate to “~/Flash Builder 4.x/sdks/4.x.x/lib/android/bin” updating the path according to the Flash Builder and SDK version you are referencing.

3. Replace aapt / adb / dx.jar with the versions from the latest SDK, which will be in ~/android-sdk/platform-tools and it’s lib subdirectory.

Now when you launch you Flex app on your device you will be presented with the RSA fingerprint confirmation dialog. Upon accepting the fingerprint Flash Builder will launch your app as usual.

MULTIPLE IOS TARGETS FROM A SINGLE XCODE PROJECT

AUTHENTICATING AGAINST AWS WITH STS

If you have been using, or are looking to use Amazon Web Services with your iOS applications, especially to back Core Data onto DynamoDB you may well have walked through the UserPreferences example which implements a Token Vending Machine (TVM) to allow your applications to request temporary user credentials to access your backend services.

Amazon have done a good job at implementing a sample TVM both for the phone side (which is still included in the SDK sample code as of SDK version 1.4.4) as well as providing TVM Java Applications that can be deployed to Elastic Beanstalk for it to talk to and all of their online documentation points you in that direction.

However, what they fail to mention unless you read through the SDK release notes, is that direct access to the Security Token Service (STS) has been available since SDK version 1.2.0 which was released way back in February 2012 and means you don’t need to bother either deploying a TVM to Elastic Beanstalk (which costs you money) or implementing the TVM code in your iOS app.

The great thing about STS is there is no additional cost over what resources you’re already using and the amount of code required is vastly less, but there appears to be extremely little documentation about how to use it, so I will run through theUsing the AWS Persistence Framework for Core Data tutorial briefly, showing what you need to do to use STS rather than TVM.

I’m going to assume you are starting with a standard Core Data application which will include managedObjectModel, managedObjectContext and persistentStoreCoordinator method implementations in you AppDelegate.

First, link the AWSIOSDK and AWSPersistence frameworks to your XCode project (1.4.4 is the current version as I write this).

The tutorial explains that you need to implement AWSPersistenceDynamoDBIncrementalStoreDelegate which requires the implementation of

- (AmazonCredentials *)credentials {


}

but which the tutorial refers you to implement a TVM for, which involves at the very least deploying a web app for and copying a lot of code from the UserPreferences example into your own project. Instead you can implement the method as follows:

- (AmazonCredentials *)credentials
  {
    if(credentials==nil) {
        SecurityTokenServiceGetSessionTokenRequest *request = 
            [[SecurityTokenServiceGetSessionTokenRequest alloc] init];

        AmazonSecurityTokenServiceClient *client = 
            [[AmazonSecurityTokenServiceClient alloc] 
                initWithAccessKey:@"ACCESS_KEY"
                withSecretKey:@"SECRET_KEY"];
          SecurityTokenServiceGetSessionTokenResponse *response = 
              [client getSessionToken:request];
          credentials = [[AmazonCredentials alloc]
              initWithAccessKey:response.credentials.accessKeyId
               withSecretKey:response.credentials.secretAccessKey
             withSecurityToken:response.credentials.sessionToken];
    }
    return credentials;
}

For the above, I have declared an AmazonCredentials property in the header file to track the credentials between calls and include the following imports:

#import <AWSiOSSDK/STS/AmazonSecurityTokenServiceClient.h>
#import <AWSiOSSDK/STS/SecurityTokenServiceGetSessionTokenRequest.h>
#import <AWSiOSSDK/STS/SecurityTokenServiceGetSessionTokenResponse.h>

Now if you complete the remainder of the tutorial you will be able to access DynamoDB using the temportary credentials, without any TVM code.

One thing to bear in mind is to ensure that the IAM user you setup to provide the credentials above should have he bare minimum of permissions required to maximise the security of your environment.

One final note, if you want to specify the region that your DynamoDB instance is running in for Core Data, rather than connecting to the default, which was made possible in SDK 1.4.3 you can include the AWSPersistenceDynamoDBEndpoint key/value pair in your configuration options as such:

NSDictionary *options = 
    [NSDictionary dictionaryWithObjectsAndKeys:
        hashKeys, AWSPersistenceDynamoDBHashKey,
        versions, AWSPersistenceDynamoDBVersionKey,
        self, AWSPersistenceDynamoDBDelegate,
        @"http://dynamodb.eu-west-1.amazonaws.com", AWSPersistenceDynamoDBEndpoint,
        nil];

AVD CRASHES ON LAUNCH (EMULATOR64-ARM QUIT UNEXPECTEDLY)

If you’ve seen the error message “emulator64-arm quit unexpectedly”  recently whilst doing Android development on a Mac, you may well have stumbled across another rather bizarre Android dev tools bug.

If you are using a second monitor connected to your computer (I do via a Kensington adapter for my MBP) and have shut down the emulator whilst it was positioned on your second monitor, it appears to cause an invalid address exception in the emulator.

The bug has been filed http://code.google.com/p/android/issues/detail?id=38371 but to get around it in the mean time you will need to edit the emulator-user.ini for each VM you have broken. You will find the file at ~/.android/avd/<emulator-name>.avd/emulator-user.ini. Open it and set window.x=0.

ENVIRONMENT AGNOSTIC NON-PUBLIC MAVEN LIBRARY REFERENCES

<repository>
<id>project.local</id>
<name>project</name>
<url>file:${project.basedir}/repo</url>
</repository>

HTTPS WITH JAVA 6 WEB SERVICES

Recently following a security review, a project I was working on needed to switch to use SSL for it’s web services. All well and good when you’re in app server land however, I was surprised at how difficult this seemed to be using the Java 6 in process web service exporter, particularly when used in conjuntion with Spring.

Given that I couldn’t find anywhere on the web that someone had published that they had managed this I thought I would share it with you.

I’m going to assume you already have a Javax web service defined, if not take a look here. Now exporting the web service using Spring couldn’t be simpler, you simply need to define an instance of your web service bean:

    <bean class='codeghost.sample.WebService"/>

and also define an instance of SimpleJaxWsServiceExport:

    <bean class="org.springframework.remoting.jaxws.SimpleJaxWsServiceExporter">
        <property name="baseAddress" value="http://localhost:8080/" />
    </bean>

The SimpleJaxWsServiceExporter will automatically find all declared @WebService annotated beans and expose them with the service name specified in the annotation.

Unfortunately, moving from there to using HTTPS takes a little investigation. Whilst not hard, it’s just not particularly well documented. You can’t just change your baseAddress to use HTTPS as that will cause an exception when you load you application context. Instead change the exporter definition to use the SimpleHttpServerJaxWsServiceExporter. This class requires a little more configuration but crucially allows you to specify a pre-configured web server.

    <bean class="org.springframework.remoting.jaxws.SimpleHttpServerJaxWsServiceExporter">
        <property name="server" ref="myServer" />
    </bean>

As you can see we are no longer specifying a baseAddress, but instead injecting the server property. We therefore need to configure the server we want to use.

First declare a HttpsServer:

    <bean id="myServer" class="com.sun.net.httpserver.HttpsServer" factory-method="create" init-method="start" autowire="byName">
      <constructor-arg ref="socket" />
      <constructor-arg value="0"/>
    </bean>

We have now called a factory method on the HttpsServer class and passed in a reference to the InetSocketAddress we want to bind to and the queue length we want the server to maintain. Crucially we have also told the bean to autowire any other properties it requires based on name.

We therefore need to specify our socket:

    <bean id="socket" class="java.net.InetSocketAddress">
      <constructor-arg value="localhost"/>
      <constructor-arg value="8080"/>
    </bean>

We also need to configure a HttpsConfigurator which is the object delegated to for provision of the HTTPS connection configuration (the name below is important as it is being autowired):

    <bean id="httpsConfigurator" class="com.sun.net.httpserver.HttpsConfigurator">
      <constructor-arg ref="sslContext"/>
    </bean>

Finally we need to create a SSLContext to be used by the configurator above. This is where it get’s slightly tricky as to be any use the SSLContext must be initialised with a KeyManager and because of the way the class specifies this be done, it cannot be done purely in config. At this point I implemented a new ConfiguredSSLContext class with a static method that I could use to create, initialise and return the SSLContext I need to finish. The crucial method looks like this (excluding error handling):

    public static SSLContext getSSLContext(String keyStoreName, String keyStorePassword, String cryptStorePassword) {
      KeyStore ks = Keystore.getInstance("JKS");
      ks.load(new FileInputStream(keyStoreName), keyStorePassword.toCharArray());
      KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
      kmf.init(ks, cryptStorePassword.toCharArray());
      SSLContext sslContext = SSLContext.getInstance("TLS");
      sslContext.init(kmf.getKeyManagers(), null, null);
      return sslContext;
    }

You can then configure Spring to be able to get a SSLContext like so:

    <bean id="sslContext" class="codeghost.sample.ConfiguredSSLContext" factory-method="getSSLContext">
      <constructor-arg value="/path/to/your/keystore/file"/>
      <constructor-arg value="keyStorePassword"/>
      <constructor-arg value="cryptStorePassword" />
    </bean>

A point to note is that the path to your keystore must be absolute, which can be a pain to manage through environments. You may therefore want to look at setting up environment filters in your build tool of choice to make this as simple as possible.

To generate a keystore, specifically for this server to load against you should use the keytool that ships with the Java SDK. On which another note of caution, if you do setup filters using Maven make sure that your keystore files are not filtered as it will corrupt them and you’ll spend hours trying to figure out why they don’t work.

Obviously, if you’re generating your own key you need to either be in a position where you can install the certificate as trusted on the client machines that will be connecting to your secure web service, or ensure that untrusted certificates are accepted in your client code. The latter wouldn’t normally be acceptable, but in the situation that all users are internal to a network you can obviously be implicit about the fact your certificate is trusted (as you generated it) without needing to install it on all target machines. Alternatively, get a certificate from a commonly trusted source certificate publishing authority, but you will have to pay for that.