Date Range: Last 7 days containing posts.
If you've ever researched ColdFusion AJAX security features such as
secureJSONPrefix, you've probably come across Ray Camden's article already (or one of his blog posts about it) but in case you haven't, before you continue I want you to at least read this post from Ray. (If I hadn't read Ray's postings I wouldn't have been able to come to the solution I'm going to tell you about without more effort. So thanks Ray!) Now, with that out of the way...
I'm using both some custom AJAX and some built-in ColdFusion AJAX goodness on a client's website. I only want AJAX calls to be able to get data from a particular page. Otherwise, I want to return a blank page to the user. In other words, I don't want someone browsing directly to
Now we all know that URL parameters can be hacked, but in my client's case if someone manages to pass in valid params that will get them results and they can bypass ColdFusion's
VerifyClient() too, then that's good enough for me. With that in mind, my ideal solution would allow me to still use
VerifyClient(), even though I'm using custom AJAX. So how can I make that happen?
Once you know that all
VerifyClient() is doing is looking for a valid
URL._cf_clientid, then it becomes a matter of passing in a valid
_cf_clientid. The next thing that comes to mind is, "How can I get that value on my own so I can use it?" Unfortunately it wasn't as simple as I hoped... To my disappointment, the value used for
_cf_clientid isn't anywhere to be found in the Client or Session scopes.
Something generates the parameter and the output looks something like this:
?_cf_clientid=C56E92048D21B1B348A3D097D842866B. I could only conclude that ColdFusion was using some sort of encrypted value and it didn't seem there was a way to access it natively. I was stuck. So I turned to my wonderful husband Dan who happens to be a ColdFusion genius, for some help and brainstorming. (Thanks for your patience Dan!)
<head> tag. So Dan suggested that I use
<cfajaximport tags="cfdiv" /> to force my page to write the global variables so that I could references them much like ColdFusion does. I didn't like that idea, mostly because importing tags I didn't need seemed wasteful. Once I got over trying to find a native way to get that same string of alphanumeric characters, I decided I should probably think about Dan's suggestion some more. I recalled recently seeing an example somewhere (though I can't recall where), that showed
<cfajaximport /> without the tags attribute. Turns out, the tags attribute is optional, so I only had to use
<cfajaximport /> in order to render the globals to the document. Ok, that feels a lot less dirty to me; I can live with this workaround.
Here's a simple proof of concept (by no means perfect) for you to view in the browser:
VerifyClient.cfm. Notice the comment in the source code that points out that the globals were generated by using
<cfajaximport /> at the top of the page. Here's the ColdFusion Code in the file that it links to (which is supposed to be called via AJAX, but faked for proof-of-concept purposes):
<cfset VerifyClient() />
The beauty of this solution is I can now use one file for both custom and built-in AJAX functionality and still use
Don't forget: You must enable client or session management in your
Application.cfc file for
VerifyClient() to work at its best. Without client or session management enabled,
VerifyClient() will not throw an error if
URL._cf_clientid exists. (Empty values and bad values will pass, but missing
_cf_clientid entirely will throw the expected error.)
Sidenote: I ran a test to see if I could get away with passing
_cf_clientid via the Form scope instead of the URL scope. No luck; ColdFusion is only checking for URL.
Happy National Regex Day!
To celebrate I'd like to share some tips for working with Regular Expressions that have helped me over the years I've been using them. I've got 5 tips to share today (#1 is already in the post on Ben Nadel's blog that I linked to but thought it worthwhile to repeat here, sorry if it is a dupe for you...)
Tip #1, for Dreamweaver Users: If you're a Dreamweaver user and need to build a regular expression, start learning about the Server Behavior Builder. When you create a server behavior, Dreamweaver generates a regular expression to match the code block(s). If you're in a hurry (or especially if you're just learning regular expressions), the regexes Dreamweaver generates can be a good starting point. You'll find the regexes it generates are in your user's Configuration in .edml files (which are XML files).
Tip #2, for CFEclipse users (assuming this works in other flavors of Eclipse as well): When you use the Search dialog (ctrl+H on the Mac), there's the obvious Regular Expression checkbox. With your focus in the Containing Text field, press Ctrl+Space to get a handy regex cheat sheet.
Tip #4, Debugging Regular Expressions: You'll most likely find yourself debugging a regex at some point or another, and for me its usually because I missed a use case. (That's when its time to update the use case document.) Any time I've got a regex that isn't quite working right, I trim it back. In other words, I do the opposite of what I described in the first part of my workflow tip above. Stop trying to match what you really want to match in its entirety, take a bit away from the regex at a time until it starts matching your use case file. (If you didn't make a use case file, now is the time to do it!) Then build that regex back up again little by little until you have it matching everything you want.
Tip #5, Application Comments: In the case of using a regex in an application (versus in Find and Replace), always, always make a comment on what that regex means in plain English terms and why you need to use it in the first place. Sooner or later, someone will look at the regex and quite possibly have their eyes glaze over -- it could be you! So do yourself and others a favor and take a couple minutes to comment it. If you're extra geeky you'll have your comment refer to your use case file so they can actually see exactly what the heck that fancy string of characters is supposed to match.
A few weeks ago I posted about needing to wrap text in a CFGRID's cell. (Read the original posted that I just updated...)
The code I provided didn't work in IE (figures!) but I've since added
display:block; to the rule and it works for me...
Here it is, new and improved:
I'm interested in hearing if anyone has a better fix, or if this doesn't work right for some use case or browser.
I Googled. I googled some more. I found lots of blogs where people asked in the comments how to wrap text in a CFGRID tag, but either no answer was given or the format was Flash.
Well, for the sanity of those on the same mission I was on, I shall blog the solution that satisfied my quest. (It may or may not satisfy yours depending on what you're trying to achieve.)
A simple line of CSS did the trick in my use case:
UPDATE: To fix IE, add
display:block; to the rule above.
That's it, one line of CSS. Hope it helps!
Macromedia, err I mean Adobe, has released Flex 2! It just so happens that lynda.com released Flex 2 Essential Training yesterday and in Chapter 1 there's a free 9 minute movie that answers the question, "What is Flex?". You'll also find a few other free movies in chapter 1, Getting Started.
If you're a regular reader of my blog, you already know that I've been working for lynda.com since late January of this year. I started out as the Web Interface Architect and have since moved to a new position, Web Production Manager.
We've hired Dan as our Web Application Architect. (If JD can "out" my new job, I can certainly "out" Dan's!)
To those who know both of us, to answer your question... Yes, I am Dan's supervisor. Nope, that's nothing new. ;-)
We're building our web team and are looking to fill a few positions in the Austin, Texas vicinity. Please visit http://www.lynda.com/jobs/ for available openings.