[[DSLog log] setLogLevel:DSLogLevelDebug];

You should then get a more verbose output in your logs from the iOS SDK, much like you get from turning on Flex logging with TraceTarget.

• FDS 2.0 = 143451
• FDS 2.0.1 = 155539
• LCDS 2.5 = 166921
• LCDS 2.5.1 = 173666
• LCDS 2.6 = 201390
• LCDS 3.0 = 254255
• LCDS 3.1 = 273934
• ADEP DS 4.5 = 315019
• ADEP DS 4.6 = 329202

I’m in the middle of rediscovering JavaScript again after several years in the Flex world, so I decided to take some time out and figure out what can be done here. In short, nothing can really be done in the Ajax application side.   The browser implementation will in general block access to any response from the third party server not letting the JavaScript anywhere near the information you might need ( in this case the authentication token).

The browser also won’t allow you to set the Authorization header on an outgoing Ajax request by default either, so using that as authentication (along with SSL) was also a non starter. That is totally understandable from a security viewpoint, and while their are hacks and workarounds, I wasn’t comfortable with recommending them.

First, let’s have a look at the request/response flow when trying to access a cross domain script via POST and Ajax.   The client and server scripts don’t really change in what I am trying to show Cross-Origin Resource Sharing (CORS) so I’ll list them here (download at the end of the post).

Step 1: Without CORS

Firstly, I want to demonstrate the request/response flow without CORS implemented.   I’ve dropped the code listed below in a folder, and I have both localhost, and a VirtualHost (called ‘cf901′) pointing to the same htdocs folder.   This allows me to make cross domain requests without leaving my development machine. The basic flow of events is:

1. Call http://localhost/tests/accesscontrol/cors-step01/client.html
2. Click on a button, which uses the code listed above to make an Ajax POST request to http://cf901/tests/accesscontrol/cors-step01/post.cfm
3. If successful, the client.html will get a simple JSON return from post.cfm

Step 1.1: Call the client.html

I’m utilising JQuery to make the Ajax calls easier, and the code is pretty simple, Base64 is a utility function found here.

$(document).ready(function() {
	//LOGIN
	$("#callMe").click(function() {		
 
		$.ajax({
			url: 'http://cf901/tests/accesscontrol/post.cfm',
			type: 'POST',
			success: function() { alert('success'); },
			error: function() { alert('error'); },
			beforeSend: function(req) {
				var headerValue = 'Basic ' + Base64.encode($("#username").val() + ':' + $("#password").val());
				req.withCredentials = 'true';
				req.setRequestHeader('Authorization', headerValue);
			}
		});	
 
		return false;
	});
});

The important points to note from the code above are:

• Setting the ‘withCredentials’ on the jQuery Ajax request.
• We add our HTTP Basic Authorization header to the outgoing request (more later)

Here are the headers of the request, there is nothing abnormal and the response is just to return the HTML page:

GET /tests/accesscontrol/cors-step01/client.html HTTP/1.1
Host: localhost
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

Step 1.2: Do a post to the different origin post.cfm

For ease of use, the server side target script is just a CFML page which echoes back some JSON.   Since I only want this data to be available to POST requests, I am doing a quick and dirty check in the script for simplicity:

<!--- I only want to return when this is POSTed to --->
<cfset httpRequestData = getHTTPRequestData()/>
<cfif listFindNoCase("POST", httpRequestData.method) eq 1>
	<cfset returnStruct = {}/>
    <cfset returnStruct.form = form/>
    <cfset returnStruct.date = now()/>
    <cfcontent reset="true"/><cfoutput>#serializeJSON(returnStruct)#</cfoutput>
</cfif>

Since we haven’t actually configured the Cross-Origin Resource sharing yet, and there is currently no HTTP Basic Auth protection, this should be a straightforward request and response if we were carrying out the action from HTML with a POST operation. As we are making a Ajax request and I’m using Chrome, it does a pre-flight OPTIONS check.   You can see the request headers below:

OPTIONS /tests/accesscontrol/cors-step01/post.cfm HTTP/1.1
Host: cf901
Access-Control-Request-Method: POST
Origin: http://localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2
Access-Control-Request-Headers: Origin, Authorization, Accept
Accept: */*
Referer: http://localhost/tests/accesscontrol/cors-step01/client.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

The important points to note from the above request are:

• We didn’t get a POST request, instead we got a Pre-flight OPTIONS request.
• There are extra headers in the request, which wouldn’t be in a normal POST from an HTML page (Access-Control-* and Origin).
• These headers give the server a chance to respond and tell the browser if it will allow the request (more on these later in Step 2)
• Note that there is no Authorization header, even though we asked for one to be added.

Step 1.3: Response to the client.html Ajax call

So what does the response look like? See below:

HTTP/1.1 200 OK
Date: Thu, 08 Dec 2011 12:24:00 GMT
Server: Apache/2.2.13 (Win32) Communique/4.0.11 JRun/4.0
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

The response looks good, an HTTP 200 but no JSON struct is returned as this wasn’t a POST request, but referring to our client it made the error callback, not the success? Lets have a look at the JavaScript console:

XMLHttpRequest cannot load http://cf901/tests/accesscontrol/cors-step01/post.cfm.
        Origin http://localhost is not allowed by Access-Control-Allow-Origin.

So basically, even though the HTTP POST from Ajax completed successfully, the browser denied the JavaScript access to the return request, as well as us denying access to the data since it didn’t come from a POST request (in reality, our web application is not responding to the OPTIONS request properly, but that is a whole different topic). With access denied to the returned information from the server to the Ajax application, we cannot do any real functionality on the web application, since by W3C specs, the only allowed HTTP methods in this configuration are by definition idempotent and cannot make any changes to the resources being accessed. So what can we do to solve this?   Cross-Origin Resource Sharing (CORS) is our friend.

Step 2: With Cross-Origin Resource Sharing

For the 2^nd step of this excercise, I’m going to introduce HTTP Basic Authentication to the sample. This was the original intent of my testing, but in the 1^st step I wanted to keep it as simple as possible.

Thankfully we stand on the shoulders of giants, and one of the ColdFusion community has kindly shared a snippet on how to implement a psudeo Basic Authentication via the Application.cfc. You can get the original code from Nathan Mische’s example.  The client.html and post.cfm are the same as in Step 1.

The flow should be fairly similar, although this time we are going to implement CORS at the Apache level.   Implementing CORS means adding some extra headers to the original response to the Ajax call.   The flow this time will look slightly different when we have it configured successfully:

1. Call http://localhost/tests/accesscontrol/cors-step02/client.html
2. Click on a button, which uses the code listed above to make an Ajax POST request to http://cf901/tests/accesscontrol/cors-step02/post.cfm and browser makes an OPTIONS request to the web server.
3. The Web Server responds with the appropriate CORS enabled response.
4. The browser then makes a 2nd POST request if it checks the CORS response and determines that the Ajax script is allowed to access the server side resource.
5. Browser passes the POST response back to the JavaScript execution.

Step 2.1: Call the client.html

Step 2.2: Client makes Ajax POST Request

The server side post.cfm is the still the same, and we get the same OPTIONS HTTP request:

OPTIONS /tests/accesscontrol/cors-step02/post.cfm HTTP/1.1
Host: cf901
Access-Control-Request-Method: POST
Origin: http://localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2
Access-Control-Request-Headers: Origin, Authorization, Accept
Accept: */*
Referer: http://localhost/tests/accesscontrol/cors-step02/client.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

<Location />
	Options FollowSymLinks
	Order allow,deny
	Allow from all
 
	Header always set Access-Control-Allow-Methods "GET, POST, DELETE, OPTIONS, PUT"
	Header always set Access-Control-Allow-Headers "Content-Type, X-Requested-With, X-HTTP-Method-Override, Origin, Accept, Authorization"
	Header always set Access-Control-Allow-Credentials "true"
	Header always set Cache-Control "max-age=0"
	Header always set Access-Control-Allow-Origin *
</Location>

If you want more detail on what these headers do, read the W3C specification as well as the Mozilla Developer Network article. I’ll give a brief description here:

• Access-Control-Allow-Methods – fairly clear, the methods that the Web Application will accept
• Access-Control-Allow-Headers – An instruction to the browser about what headers it will allow
• Access-Control-Allow-Credentials – If the browser should sent HTTP Basic Auth  or Cookie credentials in the request
• Access-Control-Allow-Origin – What origin it will allow from  (there are reports IE needs this to be set to the actual origin that the request is coming from, and that a wild card doesn’t work).

The effect of these headers (which remember can be set by the web application!) is the following response:

HTTP/1.1 200 OK
Date: Thu, 08 Dec 2011 13:54:41 GMT
Server: Apache/2.2.13 (Win32) Communique/4.0.11 JRun/4.0
Access-Control-Allow-Methods: GET, POST, DELETE, OPTIONS, PUT
Access-Control-Allow-Headers: Content-Type, X-Requested-With, X-HTTP-Method-Override, Origin, Accept, Authorization
Access-Control-Allow-Credentials: true
Cache-Control: max-age=0
Access-Control-Allow-Origin: *
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8

NOTE: Since this is the response to an OPTIONS request, I had to modify the Application.cfc to not apply Basic Authentication to that OPTIONS request, more details on why that was necessary here.

Step 2.4: Successful CORS request, perform original POST

The browser can then see that the server will allow the following, it can reconcile them with the Ajax call from the client.html:

• Allow a POST (from Access-Control-Allow-Methods)
• Will allo an Authorization header (from Access-Control-Allow-Headers)
• Instructs the browser to send credentials if it has them (Access-Control-Allow-Credentials)
• And is allowed form any other host (from Access-Control-Allow-Origin)

The browser then allows the original request from  the JavaScript to them execute:

POST /tests/accesscontrol/cors-step02/post.cfm HTTP/1.1
Host: cf901
Content-Length: 0
Origin: http://localhost
Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2
Accept: */*
Referer: http://localhost/tests/accesscontrol/cors-step02/client.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en-US;q=0.8,en;q=0.6
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3

And the server happily responds with the response, which the browser passes back to the JavaScript execution:

HTTP/1.1 200 OK
Date: Thu, 08 Dec 2011 13:54:41 GMT
Server: Apache/2.2.13 (Win32) Communique/4.0.11 JRun/4.0
Access-Control-Allow-Methods: GET, POST, DELETE, OPTIONS, PUT
Access-Control-Allow-Headers: Content-Type, X-Requested-With, X-HTTP-Method-Override, Origin, Accept, Authorization
Access-Control-Allow-Credentials: true
Cache-Control: max-age=0
Access-Control-Allow-Origin: *
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8
 
{"FORM":{},"DATE":"December, 08 2011 13:54:41"}

Step 2.5: Browser passes through server response to JavaScript execution

Looking at the JavaScript console, there should be no errors, and the $.ajax call’s success handler fires!

In Conclusion

CORS works on all modern browsers, I couldn’t find a definitive list at the time of writing nczonline.net has them listed as:

• Internet Explorer 8+
• Firefox 3.5+
• Safari 4+
• Chrome

Sample Code

Basic configuration steps to get the samples above running are:

For Step 1

• Have CF901 and Apache installed on your system.
• Add a HOSTS entry to 127.0.0.1
• Place code from ‘download/cors-step01′ into web root, and change the script variable to point to the post.cfm location

• Add a VirtualHost into your Apache configuration, and add the directives in Step 2.3
• Place code from ‘download/cors-step02′ into web root, and change the script variable to point to the post.cfm location
• You can play about with the username/password value to show Basic Auth working/failing.

Sample code is here - accesscontrol

Enjoy, if you like that sort of stuff.   If not, feel free to moan below

The quickest and easiest way to allow for deloyment onto Tomcat, is to:

1. Find your Project folder on the file system
2. Open up “project_loc/.settings/org.eclipse.wst.common.project.facet.core.xml”
3. Change the value for <installed facet=”jst.web” version=”3.0″/>, to <installed facet=”jst.web” version=”2.5″/>
4. Save the file, refresh your Eclipse project, and you are good to go.

You can then deploy your project onto Tomcat 6

Change the Web Deployment Assembly

Update build paths for:

• Flex SWCs Paths linked in Project Properties > Flex Build Path  (Class libraries and Locale Bundles)
• Any compiler paths that might have referenced the old WebContent (ie services-config.xml)

Info from an old email!

----------------
Create environment variables for
the user that Verity is running under:
VERITY_DIAG_ENABLE=1
VERITY_DIAG_DEBUG=1
VERITY_DIAG_COMP=k2idx,k2odk,locuni
------------------------------------------------------------
C\\:opt\\jrun4\\verity\\k2\\_nti40\\bin>rcadmin
-log C:rcadmin.log

K2Admin Server: localhost:9950
connected. Type ? for help.

RCADMIN - Verity, Inc. Version 5.5.0
rcadmin> hierarchyview
Service Type
[(a)dmin|(b)roker|(s)erver|(t)icket|(i)ndexServer|press enter for all]:
Hierarchy Info:
Admin Services:
Admin(1/1):

Alias : ColdFusionK2

ServerSpec : localhost:9950
 Description :
ColdFusion MX 7 Search Server

Type : Master Administration Server
------------------------------------------------------------
Server Services:
Server(1/1):
 Server level:
0

Alias : ColdFusionK2_server1

ServerSpec : localhost:9920
 Description :
ColdFusion K2Server
 Configured
State: Online

Collection(1/1):

Alias : testcollection

Description :

Access : Public

Configured State: Online
------------------------------------------------------------
Indexing Services:
Service(1/1):

Alias : ColdFusionK2_indexserver1
 ServerSpec :
localhost:9960
 Description: ColdFusion
K2 Index Server
 Configured
Service State: Online
rcadmin> statuslogset
Service
Alias:ColdFusionK2_indexserver1
Service Type For
"ColdFusionK2_indexserver1" [(a)dmin|(b)roker|(s)erver|(t)icket
|(i)ndexServer]:i
Nominal size (KB, 0 = default
300K)(300):
Verboseness (Fatal=0, Error=1,
Warning=2, Status=3 Verbose=4)(4):4
Save changes? [y|n]:y
<> SUCCESS
rcadmin>
----------------

Log files are in similar locations to following (last time I looked!)

• cf_root/verity/Data/host/log/status.log
• cf_root/verity/Data/host/diag/ColdFusionK2_indexserver1_5973/dump.log

<servers>
	<server ...>
		<properties>
			<enabled-cipher-suites>
				<cipher-suite>XXX</cipher-suite>
				<cipher-suite>YYY</cipher-suite>
				<cipher-suite>ZZZ</cipher-suite>
			<enabled-cipher-suites>

Now what cipher suites does LCDS support? Well, none, but all. Its theJRE that supports cipher suites and you can get a list of the ones supported in your application from the SSLEngine class:

——————

There are two groups of cipher suites which you will need to know about when managing cipher suites:

• Supported cipher suites: all the suites which are supported by the SSL implementation. This list is reported using getSupportedCipherSuites().
• Enabled cipher suites, which may be fewer than the full set of supported suites. This group is set using the setEnabledCipherSuites(String []) method, and queried using the getEnabledCipherSuites() method. Initially, a default set of cipher suites will be enabled on a new engine that represents the minimum suggested configuration.

——————

So if you need to use cipher suites on LCDS, there ya go.

             

		....

Then you can just refer to this in your individual channels as such:

        
            
	     

		....

As ever, see the sample services-config.xml file in the LCDS install for full details on all the properties.

All good and well, but something I didn’t realise until I was informed about it, is that the NIO channels can share the same port as the RTMP channels when using a shared nio server configuration.

That is very cool, and means only opening up one port, so for instance I have RTMP, NIOStreamingAMF, NIOLongPollingAMF, NIOPollingAMF all responding on port 2038.

In the presentation, we showed how you could easily build a simple video sharing platform, including the ability to show advert videos before and after each feature video. Using the OSMF framework, Andy showed how to build a Video Player that controlled the User Experience by forcing them to view the Advert videos, whilst allowing them to seek through the Feature video, allowing the developer to (hopefully!) monetize their service.

ColdFusion made it easy to create a simple back end to upload the videos and generate the Playlists for the videos, whilst Flex gave a nice admin interface to allow users to upload the videos and make playlists. Download the demo code and follow the configuration instructions contained within.

• Presentation PDF
• SOTR2011 – Video Platform Source Code

There isn’t documentation, but they are simple components that should be fairly clear when reading the AS code.

LoggingTextArea

This is a subclass of the mx:TextArea and includes a ‘logger’ property of type Logger.   It includes various helper methods to tie together the concepts of the Logging Framework of the Flex SDK into one class that I can just drop into a project to leverage all the categories/level etc and get my log info in a familar format.

Download LoggingTextArea.as

Sample Code

 <mx:FormItem label="Log Level" direction="horizontal"> 

 <mx:ComboBox id="logLevel" 

 dataProvider="{LoggingTextArea.LEVEL_STRINGS}" 

 change="logs.levelString = logLevel.selectedLabel" 

 selectedIndex="{LoggingTextArea.LEVEL_STRINGS.getItemIndex(logs.levelString)}"/> 

 <mx:Button label="Clear Logs" click="logs.clearLogs()"/> 

 </mx:FormItem> 

.....

<local:LoggingTextArea id="logs"

                       levelString="{LoggingTextArea.LEVEL_INFO}"

                       width="100%" height="100%"/>

You can then use (i.e.) logs.logger.debug(“My Log Id: {0}”, clientId) to add messages to the LoggingTextArea.

LoggingMessageAgentDecorator

This utility you can just wrap around a Producer or a Consumer and give it a LoggingTextArea and it will configure all the Events that I normally want to listen for.  There are a few other utility methods to send a text based message via a producer and also to change the defined channel that the message agent should use.   The decorator also exposes some properties from the MessageAgent.channelSet that aren’t by definition bindable, but are via the decorator.

Download LoggingTextArea.as

Sample Code

 <mx:FormItem label="Producer Channel" direction="horizontal"> 

 <mx:ComboBox id="producerChannel" 

 dataProvider="{producerDecorator.channelIds}" 

 selectedIndex="{producerDecorator.channelIds.getItemIndex(producerDecorator.currentChannelId)}"/> 

 <mx:Button label="Change" click="producerDecorator.changeChannel(producerChannel.selectedLabel)"/> 

 </mx:FormItem>

....

<local:LoggingMessageAgentDecorator id="producerDecorator"  loggingTextArea="{logs}">

        <mx:Producer id="producer" destination="chat" />

</local:LoggingMessageAgentDecorator>

Tying it together

I also have a simple test MXML Applicatoin that shows how currently I tie them together.  I tend to make this up as each time I am testing the actual implementation needs to be a little different each time, so just posting to show it being used.

Download TestChannels.mxml

You can get the sample as a Flash Builder 4 project, sans the LCDS jars from clicking on this link  (remember when they
always scolded you for putting a link on ‘click here’ text )  MultipleRelationshipsSample

In it’s format linked here, it’s very simple and shows one-to-many, but will most likely form the basis of a few of my LCDS related samples as it’s easy to transport and configure without any database, allowing for quick demo and additions to it’s current state.   As always, check out the lcds-samples that ships with LCDS for sample code, it contains some great examples of LCDS in action.

Don’t forget my simple Ant Script if you need to compile and don’t have Flash Builder.