I've always run into the same problem, especially with numbers. We usually had to Base64 encode the encrypted string and then URLEncode that for ultimate safety before passing it on to the next page or source application.
-- Phil -----Original Message----- From: Kris Jones [mailto:[EMAIL PROTECTED] Sent: Saturday, March 31, 2007 8:23 AM To: CF-Talk Subject: Re: Really weird encrypt problem/bug I've had issues with encrypt/decrypt when combined with URLEncodedFormat(). The issue always had to do with how strings got Decoded (not decrypted). If the encrypted value had a space in it (which I couldn't guarantee it wouldn't since we were using CF6.1), the space would be encoded as "%20". When it was Decoded, it would become a "+" rather than a space, so the decrypting would do funky things very often resulting in null pointer errors! It doesn't sound like this is your issue, but it was a thorn in my side for several months while working on this CF6 application. Cheers, Kris On 3/30/07, Les Mizzell <[EMAIL PROTECTED]> wrote: > Peter Boughton wrote: > > Odd. > > > > You can get one or two =s used by the CF encryption for padding encoded values to a certain length, so that might explain the character itself, but not really /why/ it's happening. > > > > What is in Request.encCode? > > It's a random string that's stored in another table to keep it unique > for each record. It's a short string though - usually something like > "ac74rn23". > > > > Is it definitely constant between encrypt and decrypt? > > Yup > > I've tested 100 times, and the client has tested even more, and any > combination of 5 numbers encrypts/decrypts correctly, as long as the > last number isn't a "2". > > This is an older app and because of the legacy data I'm not in a > position of changing the algorithm used at the moment. It's not > super-sensitive information that would crash the world if it leaked or > anything anyway. Nothing associated with credit cards or such. > > So, two current solutions!! > 1. Tell the client that if it's a 4 digit number with a "=" tagged on > the end, then that's a "2"! (already implemented) > 2. rereplace the "=" with a "2" after decrypt - heh... > > For the life of me, I see NO reason why/how this could be happening! > It's a very odd thing indeed! > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| ColdFusion MX7 by Adobe® Dyncamically transform webcontent into Adobe PDF with new ColdFusion MX7. Free Trial. http://www.adobe.com/products/coldfusion?sdid=RVJV Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:274301 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
