|
Current Filter:
Category: ColdFusion
Date Range: Last 7 days containing posts.
(clear
filters)
If you've ever researched ColdFusion AJAX security features such as VerifyClient()
or secureJSON
or 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 callbyajax.cfm
.
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!)
Dan noticed that the URLs generated by native ColdFusion AJAX calls use some global JavaScript variables that ColdFusion sets right after the opening <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):
<cftry>
<cfset VerifyClient() />
<cfcatch>
NO!<cfabort>
</cfcatch>
</cftry>
YES!
The beauty of this solution is I can now use one file for both custom and built-in AJAX functionality and still use VerifyClient()
.
Don't forget: You must enable client or session management in your Application.cfm
or 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.
Posted by ~Angela | Comments (0) | Add Comment | Permalink
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 #3, a Workflow Tip: When trying to come up with that perfect regex, take the time to build a static page or two that has what you want to match in it. Essentially, create a use case document. Then use your favorite regex capable Find and Replace tool to work up to creating the perfect regex. For instance, if you have a huge string to match, start by trying to match only the first 5 characters then add on to your regex and test again. When you've got it matching your use cases, then go ahead and plug it into your ColdFusion or JavaScript code (you don't use other code right? ;-))
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.
Posted by ~Angela | Comments (3) | Add Comment | Permalink
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:
div .x-grid-cell-text{white-space:normal;display:block;}
I'm interested in hearing if anyone has a better fix, or if this doesn't work right for some use case or browser.
Posted by ~Angela | Comments (2) | Add Comment | Permalink
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:
div .x-grid-cell-text{white-space:normal;}
UPDATE: To fix IE, add display:block;
to the rule above.
That's it, one line of CSS. Hope it helps!
Posted by ~Angela | Comments (8) | Add Comment | Permalink
It's true; Adobe sells ColdFusion. In fact, they have for a few years now. Ever since they acquired Macromedia.
Gotcha...Just like last time.
Posted by ~Angela | Comments (1) | Add Comment | Permalink
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.
Enjoy!
Posted by ~Angela | Comments (0) | Add Comment | Permalink
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.
Posted by ~Angela | Comments (4) | Add Comment | Permalink
Comment from Sheran on 6/7/2008
Thanks for the information angela.
You're welcome. Glad to see a few people found this useful. ~Angela
Comment from Patrick McElhaney on 6/1/2008
Great tips. In fact, I think each one is progressively better!
Don't forget to enter in Steve Levithan's contest, if you haven't already.
Thanks Patrick. :-) I missed out on Steve's contest this year, but that's alright; I still enjoyed the new holiday. :-) ~Angela
Comment from Steve on 6/1/2008
Good stuff. You really should submit this here.
Bummer, I missed out... Oh well. Thanks for the suggestion anyhow. ~Angela