Welcome!

You will be redirected in 30 seconds or close now.

ColdFusion Authors: Yakov Fain, Jeremy Geelan, Maureen O'Gara, Nancy Y. Nee, Tad Anderson

Related Topics: ColdFusion

ColdFusion: Article

Implementing HTTP Basic Authentication

Route around many of the common limitations of traditional forms-based authentication

Most ColdFusion applications that require users to be authenticated follow the pattern laid out in the official ColdFusion documentation and in the ColdFusion MX Developer's Guide.

This HTML forms-based method is perfectly serviceable, but as applications become more complicated it's not uncommon to run across issues with session expiration and deep linking/bookmarking. This article describes an alternative method of implementing user authentication that's based on the mature and time-tested authentication scheme laid out in the original HTTP specification. Without making the application significantly more complex, it can route around many of the most common limitations of traditional forms-based authentication.

An Overview of Forms-Based Authentication
To start off, let's take a look at some typical ColdFusion code that uses forms-based authentication from the point-of-view of a Web browser. A typical application might have code in the Application.cfm file that looks something like this:

<cfif NOT IsDefined("SESSION.login")>
    <cfif NOT IsDefined("FORM.login")>
      <cfinclude template="loginForm.cfm">
      <cfabort>
    <cfelse>
      <!--- Process login information --->
    </cfif>
</cfif>

Let's look at the series of requests and responses that occur between a Web browser (WB) and a server (S) when the user requests a page that's protected by this kind of authentication code:

WB: Please send me the page called /index.cfm.
S: OK, here's the page called /index.cfm. (The server sends a page containing a form with text fields for user name and password and a submit button.)
WB: (After the user fills in the form and clicks the submit button) Here's a POST to the page called /index.cfm.
S: OK, I processed the submission and here's the page called /index.cfm.

Notice how the server claimed the two pages it sent were both /index.cfm? That's an example of one problem with forms-based authentication: it misrepresents the resources identified by URLs. To illustrate another problem, take a look at what happens later, after the user takes a break from using the application and the session expires:

WB: Please send me the page called /administrator/addUser.cfm.
S: OK, here's the page called /administrator/addUser.cfm. (The server sends a page containing a form with text fields for user name and password and a submit button.)

Since the session expired, the server responded to the request by providing the login form again. Even if the form provides some information about why the user needs to log in again, the user may become confused, and at the very least is inconvenienced.

There are other ways to implement forms-based authentication (such as using <cflocation> to redirect the browser to the login form instead of using <cfinclude> to send it in place of the requested page), but the basic issues are the same:

  1. Forms-based authentication misrepresents the resource requested by the browser. Depending on the implementation, it claims the login form is the resource that was requested, or it sometimes claims that the resource requested is located somewhere else (that "somewhere else" being the location of the login form).
  2. It forces the user to understand technical issues like session expiration.
  3. Since it's dependent on session cookies, it's not easily scalable to cluster environments and doesn't work if the browser has cookies disabled.
  4. Since it's dependent on the end user to read the login form and understand that it's not the resource the user requested, it's not compatible with alternative user agents
More Detail: URLs and HTTP Status Codes
What's all this talk about "misrepresenting the resource," you say? It boils down to URLs and status codes.

Each time the browser requests a page, it specifies the exact resource (page) it's requesting. This resource is identified by the URL and a basic tenet of HTTP is that two requests for the same resource (assuming there's no form submission happening) should return exactly the same result (this is closely related to the property of HTTP requests called "idempotency," the principle that GET requests shouldn't change the state of the resource being requested). When the server sometimes sends a login form and sometimes sends the actual page, it's breaking this one-to-one correspondence between the URL and the resource.

Each time the server responds to a request, it sends a status code that very succinctly tells the Web browser the "gist" of its response. Most of the time (when it's serving ColdFusion pages at least), the server sends the status code 200 ("OK"), which means "this page I'm sending you is exactly what you asked for." If instead of executing the page the user requested, the server is sends a login form, it's lying to the browser when it says it found what the user asked for.

When the ColdFusion server processes a <cflocation> tag, it sends the status code 302 ("Found"), which means "the page you're looking for is temporarily located somewhere else and I'm sending you its location." If the address the server sends isn't actually the page the user requested, but a login form, it's lying again.

These distinctions may seem pedantic. But every Web browser since NCSA Mosaic has been raised speaking HTTP as its native language and there's a surprising amount of potential to be leveraged in modern browsers when you respect the true meaning of the terms in that language. And sometimes when you ignore the rules of HTTP you get burned - a notable example of this was when Google released a beta of its Web Accelerator and lots of developers who had ignored the principle of idempotency found that their Web sites were breaking.

Basic Authentication to the Rescue
All the way back at the dawn of the Web (May 1996, to be specific), when Tim Berners-Lee codified the rules of the Hypertext Transfer Protocol (HTTP/1.0), he and his co-authors considered the problem of how to secure resources on the Web and their answer to the problem has come to be known as HTTP Basic Authentication. With Basic authentication, the initial dialogue between Web browser and server looks more like this:

WB: Please send me the page called /index.cfm.
S: Sorry, that page is part of an application called "MyApplication." You can't see that page without providing a user name and password. Here's a page to tell the user why he can't see the page he asked for.
WB: (Prompts the user for a user name and password.) Please send me the page called /index.cfm - and here are the user's credentials to access that page.
S: OK, I processed the credentials and here's the page called /index.cfm.

Doesn't that look like a much more productive exchange than when the server was telling all sorts of lies about the resources it was sending to the browser? In fact it is more productive and here are a few reasons why:

  1. HTTP status codes and URLs are used exactly as they were intended.
  2. Once the browser knows the user's credentials for the application, it can continue to provide them when needed without prompting the user again (more on this below). Depending on your application, this might mean the end of session expiration!
  3. It's not dependent on keeping login credentials in the session scope, so it even works when browsers have cookies disabled. (Your application may still need to use session-scope variables for other purposes.)
  4. It allows alternative clients (such as command-line and automated user agents) to access your application, unlocking the potential for new and exciting uses of the data in your application.
Web Server-Integrated Basic Authentication
Basic authentication doesn't have to be implemented in application code. All the most common Web servers (including Apache and Microsoft's Internet Information Server) allow the administrator to protect resources with Basic authentication by setting some configuration parameters. In some cases, this may be sufficient, but if you want to validate the user login information against an existing user database (the one built into your application, for example), you'll almost certainly find it easier to keep the authentication code integrated with the rest of your application.

More Stories By Patrick Correia

Patrick Correia is a Web developer for Clough Harbour & Associates LLP, an east coast multi-disciplined engineering firm. A Certified Advanced ColdFusion MX Developer based in Albany, New York, he has spent the last five years developing ColdFusion-based business process improvement solutions for the firm's numerous municipal and private clients.

Comments (1) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
MikeR 06/08/06 11:43:56 PM EDT

Interesting article but it failed to mention the huge flaw with basic auth.

Basic authentication can't be used for most real-world sites because:
(1) There is now way for the user to log out short of closing all browser windows.
and (2) There is no practical way for the site to logout or timeout a user.

IoT & Smart Cities Stories
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...