This marks the first installment of a new monthly column, Community Focus, and the end of a long-running column, Tales from the List.

Due to the rapid growth of ColdFusion community news and events and the growing popularity of blogs (Web logs) amongst ColdFusion developers, it no longer seems appropriate to focus on one list server for a "messages from the trenches" type article. Each month, Community Focus will explore trends, Macromedia news, events, blog entries, and list server threads, focusing on what's going on in the community… or at least one facet of what's going on in the community. This month's issue is focused heavily on security, so following a series of blog entries, I will join suit and do the same.

This month's column is about securing applications or, rather, problems with securing applications. Macromedia recently released a TechNote written by Sarge (www.macromedia.com/support/coldfusion/ts/ documents/loginstorage_caching.htm) in which he describes a problem with the CFLOGIN tag. Apparently, when the CFAPPLICATION tag "loginstorage" attribute is set to "session" the CFLOGOUT tag doesn't always properly delete the internal variables used to store session information, only the session variables. This can result in one user logging out and another user logging in on the same browser only to receive the other user's credentials.

Ray Camden blogged about it (Ray's blog can be found at www.camdenfamily.com/morpheus/blog/) and offered a solution that basically consists of doing a CFLOGOUT whenever "session.user" is not defined. This works fine if you don't assume that all users are logged in, but is a bit of a hack in that sometimes you want to assume authentication and just make people who haven't submitted a login form seem as authenticated as an "anonymous" or "guest" user.

For those of you who are not aware, JRun and many/most other Java applications use a standard Java package called JAAS (Java Authentication and Authorization Service) to handle security. ColdFusion, under the hood, also uses this framework to handle authentication/authorization whenever you use the CFLOGIN/CFLOGOUT/CFLOGINUSER tags or getAuthUser() function. I recently blogged about problems with authentication against the JAAS framework in a clustered environment. As many of you may already know, I am a freelance consultant currently working on a contract in London. My current client offers several products to clients and has a single common authentication/authorization module. All of their software offerings are developed in ColdFusion, Java, or a hybrid of the two. We also recommend running our software in a clustered environment. To our dismay, we've found that JAAS authentication on one server in a JRun cluster does not fail-over to other servers in the cluster.

The same holds true for the CF authentication/authorization tags and functions. I blogged about this at www.horwith.com.

After writing the TechNote, Sarge made an entry in his blog (found at www.sargeway.com/sarge/) that describes how using cookie storage for authentication (via the CFAPPLICATION "loginstorage" attribute) doesn't work properly either because sometimes when a session times out, the authentication cookie remains. Even though the session is empty, getAuthUser() still returns the last logged-in user's info (in the same browser). To expand on this it's also worth noting that if you authenticate against a "pure JAAS module" (e.g., a JAAS module written in Java, not CF) you are seen as logged in by ColdFusion; if you do a CFLOGOUT, it does not log you out of the Java application - even with common context roots and/or EAR/WAR deployment.

One last note about security blogs in the community - just so that it's not all about implementation problems per se. I also blogged about a somewhat easy fix to the problem, whether you're using pure Java or the CFML implementation (CFLOGIN/CFLOGINUSER/CFLOGOUT). The J2EE world frequently preaches use of design patterns - not too often do you get to see a good real-world example of a design pattern fixing a specific problem (though Hal Helms' article in this month's issue does happen to show one). Security in CFML applications is often accompanied by a "user" (or other) CFC instance persisted in the session scope. But wait - like JAAS, there are problems doing this in a clustered environment. When a session variable is created on one server in a cluster and "carries over" to another server in the cluster, it's known as "session replication". This allows Server A in a cluster to set a variable in the session scope and if, on a subsequent HTTP request, that same user's request went to Server B, the session variable would still exist.

In order for this replication to work, all variables stored in the session must implement the Java Serializable Interface. Unfortunately, ColdFusion Component Instances are not serializable, which means that if you want your CFML application to work properly in a clustered environment that uses replication, you cannot persist CFCs in the session scope. Fortunately, the J2EE "facade" pattern can be used to work around this limitation.

The idea is to create a CFC - a facade - that directly accesses the session scope. The CFC should have get/set methods for all of the values in your session. You then go to any CFC that your application puts an instance of in the session scope, and replace any references to variables that it's storing in the "variables" scope or the "this" scope with calls to get/set methods in the facade CFC. The last thing you'd want to do is stop persisting the CFC instance(s) in the application. There are two drawbacks to this approach. The first is a performance hit because your application now creates the instance(s) on every request. The second is that, from a design point of view, the data is no longer protected within an object. For the same reason that you shouldn't use the "this" scope in CFCs, you also shouldn't be storing object properties in the session scope rather than the object itself. "Session" and "this" are both scopes that may be accessed from outside the component, thus making it impossible to guarantee the integrity of the data or to enforce business logic when these values change.

If you want a simple example showing the facade pattern used in this way to get around the CFC serialization issue, I've put one at www.horwith.com/downloads/facade_fix_sessioncfc.zip. Note that I wrote this pretty quickly; it's a simple example, but it illustrates the idea. The code should be self-explanatory.

So, that does it for the first installment of Community Focus. Next month we'll examine more recent news in the community and will also begin preparation for MAX! We'll also be experimenting with more CFDJ issue and article formats, including more multipart articles and some other things I'd like to see (and think you would, too) in the near future.