Crypto.cfc For Hmac-SHA1, Hmac-Sha256, and Hmac-MD5 Code Generation In ColdFusion
Last week, I talked about using binaryEncode() as an easy way to hex-encode binary values in ColdFusion. This is a processing step commonly used when generating a Hashed Message Authentication Code (Hmac) needed to sign a 3rd-party API request. As a follow-up to last week's post, I wanted to present a project that I created for generating Hmac values prior to ColdFusion 10. Crypto.cfc exposes the HmacSha1(), HmacSha256(), and HmacMD5() methods for creating Hmac values with the SHA-1, SHA-256, and MD5 algorithms, respectively. Each method takes a Key, an Input, and an optional encoding argument.
Project: View Crypto.cfc on GitHub.
The Crypto.cfc component is really small, providing only a light-weight facade to Java's underlying Crypto library:
- hmacMd5( key, input [, encoding] )
- hmacSha1( key, input [, encoding] )
- hmacSha256( key, input [, encoding] )
The optional encoding argument defaults to "Hex" (ie. hexadecimal encoding); but, it also supports "base64" and "binary" if you want to return the raw byte array.
The most exciting part of this project, for me, however, is the fact that I actually released this project with Tests! In addition to the Crypto.cfc component and some examples, I also include a suite of MXUnit tests with the repository! This is the first time I've ever released anything with Tests, so it's kind of a big deal. I'm feeling pretty proud of myself :D
| |
|
|
||
| |
 |
|
||
| |
|
|
I'm still writing my tests after I write my code; so, it's not truly "test-driven" yet. But, I'm getting more and more comfortable with the idea of having unit tests and making them part of my development process.
Reader Comments
Well done. It is hard to flip your development process around to writing tests first.
Heck, I've been writing unit tests for years and I still often find myself starting a project without the word "test" in my vocabulary until after I have some operational code in place.
It's kind of embarrassing really.
Anyway, I think it is cool that you are releasing this project with tests - not because you took the time to write tests for yourself or your project but because more having tests like this out in the public will make it easier for people new to unit testing to understand their role.
@Bill,
It's definitely an exciting step for me. Part of the reason I don't start with tests is because often, I have no idea what the "API" will look like in the beginning. So, I think I won't know how to write my tests.
But, the reality is probably the opposite - probably, sitting down and trying to write the tests first will help think about what the API *should* look like, rather than what it will look like in the end.
Of course, it's fun to just jump in and start coding! :D
I'm glad to hear that people, like yourself, with lots of TDD under their belt, still jump in and code - it makes me feel like I'm on the right track!
@Ben,
Is there a reason you used underscores to scope your "private" functions rather than actually declare them as private? Was it so you could test them?
@Tony,
I don't like the way ColdFusion handles private methods - requiring the use of the "variables" scope vs. the "this" scope for scoped-method-reference.
It also causes problems with named vs. ordered arguments when using variables-scope method calls. Though, I think this is a bug that might have been fixed in CF9? I can't remember.
By using an "_" prefix, it does two things:
1. It keeps my ColdFusion and JavaScript more symmetrical (not a technical requirements, but something that I enjoy).
2. It allows me to use "this" for referencing both public and private methods - something that I personally enjoy.
That said, this is something that I've only started doing with CFScript. When I was using all tag-based components, I made all my methods Public with no special naming conventions.
I guess I'm still just finding my way :)
@Ben
re:named arguments
Yes, it was fixed in CF9.
re: 2.
This still makes me cry. If you can use `this` to access them then they aren't private. Can we instead call them Nadel-Only-Public functions, or Ignore-Me-I'm-A-Pink-Elephant-Public functions? It's hard enough teaching proper function access restrictions without your fans (of which I am one) saying "But Big Ben doesn't use them and he's Epic!" Responding with "Yes, he is Epic, but he's promoting bad practice" doesn't fly.
@Grumpy,
Ha ha, good sir, I certainly can't argue with anything you're saying :) One thing that I have seen people do is completely leave off the "this" and the "variables" prefix when referring to internal methods and properties. I suppose I *could* try that to see how it feels. I have a lot of years of momentum behind wanting to use scope references -- hard to overcome.
Yeah, in CF8 we skipped the scope declaration. varscoper is happy enough with it, and it works. Since CF9 we scope with Variables.
@Grumpy,
Yesterday, I tried writing some code without putting any scope prefixes on method calls. AND, I actually made some of the methods Private. Still not sure how I feel about it. I'll give it some more time.
If you decide to stop, don't tell me, so I can just point people at your last comment that says that you're giving it a go. :-p
@Grumpy,
Ha ha, no problem ;)
HiBen - I've just sent a snippet of code to moz.com (previously SeoMoz) for authenticating with their API - Thanks for creating the CFC, it saved me heaps of time
Martin
@Martin, I'm trying to use your code to get moz api response without success.
I think this string:
is causing problem. Could you tell me if I'm right?