Category: Coldfusion
Shared client variables in ColdFusion 8
Idea of this HOWTO was born an answer to StackOverflow question Sharing login credentials between ColdFusion severs? The task was to keep users logged in while navigating between different servers. In this HOWTO I'll try to show the steps how to achieve such result in easy way.
Create empty database on one of servers (I've created MySQL one). Create datasources pointing to this DB on all CF servers.
Use created datasource as Server Settings < Client Variables > client sessions store with name SharedSessions (we'll use it later).
Please note that you need to uncheck when creating store at second server:
How this can be used? Let's use same example as at SO.
<cfapplication
name="shared_session_test"
sessionManagement="true"
clientmanagement="true"
clientstorage="SharedSessions" />
Here's the trick: we set same clientstorage attribute on both servers.
To check that system works we'll try to keep basic login between two servers:
<cflogin>
<cfif IsDefined( "cflogin" ) and cflogin.name eq "admin" and cflogin.password eq "admin">
<cfset user_roles = "administrators" />
<cfset user_name = cflogin.name />
<cfset user_password = cflogin.password />
</cfif>
<cfif IsDefined( "user_roles" )>
<!--- push login params into shared client scope --->
<cfset CLIENT.user_roles = user_roles />
<cfset CLIENT.user_name = user_name />
<cfset CLIENT.user_password = user_password />
<cfelseif IsDefined( "CLIENT.user_roles" )>
<!--- restore login params from shared client scope --->
<cfset user_roles = CLIENT.user_roles />
<cfset user_name = CLIENT.user_name />
<cfset user_password = CLIENT.user_password />
</cfif>
<cfif IsDefined( "user_roles" )>
<cfloginuser name="#user_name#" password="#user_password#" roles="#user_roles#">
<cfelse>
<!--- authentication failed - send back 401 --->
<cfsetting enablecfoutputonly="yes" showdebugoutput="no">
<cfheader statuscode="401">
<cfheader name="WWW-Authenticate" value="Basic realm=""MySecurity""">
<cfoutput>Not authorized</cfoutput>
<cfabort />
</cfif>
</cflogin>
To notify the target server which variables to use, we have to pass the client token. This can be done via URL:
<cfoutput><p><a
href="http://other.host.com/shared/index.cfm?#CLIENT.urltoken#">falcon</a></p></cfoutput>
It can be done more transparently if you are working with subdomains. Token can be put into cookie with domain *.host.com, that should make cookie visible for all subdomains.
The best part is that it doesn't matters, which OS, web-server software and database used at each server. Everything should work without problems. Thanks ColdFusion for making our lifes easier! :)
More reading:
Configuring and using session variables
Configuring and using client variables
Posted by Sergey Galashyn on May 17, 2009 at 1:06 PM - Categories: HOWTO | Coldfusion
Writing a Flex Widget. Easy.
Flex and Coldfusion seems like made for each other. What I'm saying? Yes, Coldfusion and Flex ARE made for each other! Adobe spend time and effort to make Flex best tool for creating rich user interface for internet applications and in same time, make Coldfusion best data back-end for Flex. To demonstrate and educate (myself) about Flex and Coldfusion, I plan to write series of articles about different aspects of Flex, it's interoperation with Coldfusion, data transport etc etc. I plan to create simple info widget as a guinea-pig.
Adobe miraculously joined it's young client-side technology, Flex, with veteran server platform - Coldfusion. This was technology breaktrough that other companies only dream about and running off the leg chasing Adobe with their products (SilverFX, JavaLight... what their names again ?). Creating powerful web-applications with rich user interface and robust data back-end never been simpler.
To the point.
Flex application is obviously a Flash movie, and it can communicate with server back-end in several ways - using simple REST calls, using Flash Remoting, consuming Web-service and calling it's methods, using Data Messaging and Publish/Subscribe.
With AJAX you'd probably use REST to call URL and receive XML or JSON data back to application. For Flex it's totally legitmate way - with Flex's URLLoader class you may prepare HTTP request, call remote page and then parse what's returned into ActionScript data structures.
Flex Remoting is more sophisticated technology that uses AMF binary protocol to transfer data to Flash movie. Flash developers were using Flash Remoting from version MX and Coldfusion MX has great support for Flash remoting (this is year 2002). Since AMF is binary protocol, it may pack data more efficiently, cutting transfer time. AMF encapsulates native ActionScript data structures, so your data need no XML wraps, this cuts off time spent on XML parsing (usually, a lot of time). Look at this chart and learn why you'd want to use AMF. There's lots written about AMF out there, if you need details.
Data Messaging and Publish/Subscribe are advanced tecniques delivered by LiveCycle Data Services. Using it, you may push changing data to client (eliminating redundant server polling by client), you may update datasets on clients when one of client changed data, you may prevent collisions when two clients changing same data.
For real world sample, I will use Flash Remoting. It's native, it's fast, it's easy to implement. All ways round, it's best for linking Flex to Coldfusion by default. If your application demands, consider advanced metods, but for most tasks Flash Remoting is the best.
To bake this, you will need 2 pieces of code - one to produce data on Coldfusion side and second to consume data on Flex side.
To use Flash Remoting in Flex, you should have destinations - descriptions of Coldfusion components that Flex will read and use. Without specifying destination, Flex will be unable to find CFC you are referring to. Fortunately, Coldfusion has one pre-defined common destination called Coldfusion that simply points to Web Root of your server. This allow Flex to find CFCs under Web Root by fully qualified name in dot-notation. For example, my Coldfusion is linked to Apache and project reside in folder /project/components under Apache /htdocs folder. The CFC itself is called data.cfc. So, Flex is referring to it as project.components.data with destination named Coldfusion. You may want to store CFCs outside Web Root folder by security reasons - in this case you should create destination that will point to that specific folder.
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" creationComplete="{roData.getMessages()}">
<mx:RemoteObject id="roData" destination="ColdFusion" source="project.components.data" />
<mx:DataGrid dataProvider="{roData.getData.lastResult}" />
</mx:Application>
On server side, it is data.cfc component in /project/components folder that is answering our call. See that 'source' attribute is describing same path to CFC in 'dot-notation', and without .cfc notation. The component itself is rather easy to understand:
<cfcomponent displayname="data" hint="Data source" output="false">
<cffunction name="getData" returntype="Query" hint="Return text data" access="remote" output="false">
... code that queries database and returns query object ...
</cffunction>
</cfcomponent>
That's it. Yes, it's that easy. Such widget can sit on side bar of your website, telling people latest news, for example. Of course, this is basic example. However, it will take you no more than half-hour to add filter to data (e.g. language selection for news feed), or read external source, like Twitter feed. Hundreds of options exists, however basic approach is always the same.
Posted by Rodion Bykov on March 30, 2009 at 2:39 PM - Categories: Flex | Coldfusion