NYCPHP Meetup

[Chris Shiflett]

--- Hans Zaunere <hans at nyphp.org> wrote:
> The problem I see, as you eluded to Adam, is the lack of a MD5 function
> builtin to CF.  Is this really the case?  I may seem like I'm being pedantic,
> but I need to leave the slightest footprint [impression] on the CF side... no
> additional files, DB access, etc.  I'm limited to this because the CF piece
> is not mine, and as I found out during the server fiasco, the ISV is *very*
> quick to point the finger.

That's an unfortunate situation that is going to make things difficult for you.
As I recall, CF's cryptographic functions are extremely weak. In fact, I
remember there being an encrypt() and decrypt() only. I had to write CFX tags
for triple DES and MD5.

Since you (they) are running on Windows, you probably won't have to write your
own like I did (mine were for Solaris). You can search for cfx_md5 on Google or
something and find a few. This violates your idea of "slightest footprint", but
I'm not sure if you'll find any better way. CF's encrypt() function is a
tow-way, so it will be way too big for what you need to do.

> So I'm left with only being able to put a tiny link, minimally generated by
> builtin CF functionality.  Hence, my thinking a MAC address would at least be
> enough to force most medical students into logging into the CF page first,
> while keeping even this ISV from placing blame.

Is there session management on the CF side? Are they using the registry as the
data store? If so, you can at least leverage that for persistent storage. Also,
you can pass the cfid and cftoken yourself using PHP, so that you keep up with
sessions on the PHP side, and the cfid:cftoken combination is just another
unique identifier in the same way that PHPSESSID is.

This will make it "work", and you can then investigate either cfx_md5 in
combination with my earlier suggestion(s) or the MAC address idea you have.

Chris