ColdFusion Tips and Tutorials

Keep Coding,
Nathan Stanford
President/CEO
C.F. Concepts, Inc.
http://www.coldfusionmonthly.com
http://www.cftipsplus.com

If you have suggestions for articles send them to us.
If you would like to write for cftipsplus.com
send us an email to:

admin@cftipsplus.com

IF YOU WANT TO BE AN AUTHOR SEND IN YOUR COLDFUSION TIPS.

Remember this is a great way to get your name known in the
ColdFusion Community.

Visit this site. If you have plans to get training here is a company that provides Advanced, Intensive ColdFusion Training. Check them out.

http://www.coldfusiontraining.com/index.cfm?ref=cftipsplus

Monthly access to new articles written by industry-leading ColdFusion experts. A fully-functional application that accompanies each issue.

Full access to all issues, past and present (with a one year paid subscription). The chance to be seen in our "Community Spotlight" corner, which showcases new writers and emerging talent

Overview
The application will need to test the browser during login, tell ColdFusion the results, have ColdFusion remember the results, and have ColdFusion generate just the javascript the client needs. During login, test for the browser characteristics you need to know. You could write to a form variable, URL, or cookie to tell ColdFusion the information it needs to know. Since the login page feeds a form anyway, this example will change a form variable for simplicity. The authentication page will store the browser information as a session variable. When the user goes to subsequent pages, if the session variable doesn't exist, the user is directed back to the login page. If it does exist, ColdFusion selects the appropriate javascript based on the original test at login.

Login
Here's code for a simple login; call it login.cfm. It removes ColdFusion's session ID cookie. (For reliability, always use a value when deleting a cookie.) It provides a simple login form. It uses a simple test to get the browser family. There are published tests that run for hundreds of lines and pick up many nuances about a browser. You could easily afford to use a complex test at this point if you were following this tip; because, you'd only need to run it once per session. When the page has finished loading, the javascript test runs and changes a hidden field of the form; you'd use multiple fields in real life: one for each browser characteristic you want to remember.

<cfcookie name="CFID" expires="-1" value="dummy">
<form action="card.cfm" name="check" method="post">
Enter employee ID starting with "f"; others fail:
<input type="text" name="employeeID" value="" size="10" maxlength="8">
<input type="hidden" name="bfamily" value="">
<input type="submit" name="submit" value="OK?">
</form>
<script language="javascript">
if (navigator.appName == 'Netscape')
document.check.bfamily.value = 'NN';
else document.check.bfamily.value = 'IE';
</script>

Check Credentials
Create a page that checks credentials; call it card.cfm. It begins by defining two forms that the user will never see. To avoid confusion in this small example, it uses forms instead of the dreaded cflocation tag to change the current page. If the cflocation tag is used, then 1) the CFID cookie doesn't get deleted when the user is bounced to the login, and 2) the URL window of the browser continues to display "case.cfm" instead of "p/inside.cfm". (It still goes there, but it doesn't tell you that.) Using a form sidesteps these problems. If the forms don't have at least one field, Netscape will ignore them. If the forms don't have a submission method of "post", Netscape will display the field in the URL. That's why each form has a submission method and a dummy field.
If the employee ID starts with "f" - insert your real test here - it sets session variables and advances the user to the inside of the application: inside.cfm in directory "p" (for "production"). If it's not, it dumps the user back at the login screen. Enabling session management lets ColdFusion handle the rest automatically. In real life, you'd give session.OK a time-based secret relationship with the session ID to discourage tampering.

<form name="forward" action="p/inside.cfm" method="post">
<input type="hidden" name="dummy">
</form>
<form name="backward" action="login.cfm" method="post">
<input type="hidden" name="dummy">
</form>
<cfapplication name="frugalJS" sessionmanagement="yes">

<cfif ucase(left(form.employeeID,1)) eq "F">
<cfset session.empID=form.employeeID>
<cfset session.OK="asdf">
<cfset session.bfamily=form.bfamily>
<script language="javascript">
document.forward.submit();
</script>
<cfelse>
<script language="javascript">
document.backward.submit();
</script>
</cfif>

Block the Production Directory
You'll use Application.cfm to block the "p" directory. This code automatically becomes part of every cfm page in the directory. Create the directory and put this code in Application.cfm inside it. This code enables session management and tests to see that the user is logged in. Whatever formula you use to assign session.OK must match the test you use on this page. If the user isn't logged in, bounce the user to the login screen.

<cfapplication name="frugalJS" sessionmanagement="yes">
<cfif not ( isDefined("session.OK") and (session.OK is "asdf") )>
<cflocation URL="../login.cfm">
</cfif>

Work Inside the Application
Within the application in the p directory, use the browser data recorded during login to pick browser-dependent javascript to be sent to the client. The session variable bfamily tells ColdFusion which code to use; the other code won't reach the browser. This code is odd. It lets you type outside the box but puts the results into the box. Call it inside.cfm.

If the browser is Netscape Navigator, then each keypress has to be captured and fed to a regular function in order to be used. The "captureEvents" code does this. The code that depends on it uses the "which" function to get the ASCII value of the character, then converts that code to the character itself. Finally, it adds the character to the current value of the field.

If the browser is not Netscape Navigator, the code assumes it's IE. then each keypress has to be captured and fed to a regular function in order to be used. The "onkeypress" characteristic of the document can be used directly. The rest is similar to the code for Netscape.

To see a function dependent on <cfoutput>#session.bfamily#</cfoutput>,
click and then type OUTSIDE the box.<br>
<form name="toss">
<input type="text" name="look">
</form>
<script language="javascript">
<cfif session.bfamily is "NN">
function myFun(myEvent) {
var keyCode = myEvent.which;
var keyChar = String.fromCharCode(keyCode);
document.toss.look.value += keyChar;
}
if (document.captureEvents) document.captureEvents(Event.KEYPRESS);
document.onkeypress = myFun;
<cfelse>
function document.onkeypress() {
var keyCode = window.event.keyCode;
var keyChar = String.fromCharCode(keyCode);
toss.look.value += keyChar;
}
</cfif>
</script>

Try It Out
Now to see the results. Go to login.cfm and try a bad login. Then, enter p/inside.cfm directly to watch the code throw you back to login.cfm. Try a good login and watch as it brings you through card.cfm to p/inside.cfm. Click and type outside the box to prove the browser-dependent code is working. View source to prove that only the appropriate code is reaching your browser. Then try the whole thing again with the flavor of browser you didn't use the first time.
You can surely extend this technique. See if you can keep Netscape from displaying the words "Transfer interrupted" when card.cfm forces the browser to a new page. Perform a more detailed browser test at login. Build your application. Then, tell us what you've learned.
=Marty=