Teddy & John, now you’ve got me curious. I have a contactID field in my database for each contact. Is that what you mean by UUID? Why would this be better?
I think using the eMail address is better because it’s possible that someone’s email address could be in the database twice (Please no comments on 3rd normal form!) This way, I can unsubscribe anyone who has that eMail address, not just the unique record. Seems better for the users. Thanks for the help, and if I’m missing something, please let me know! Clarke From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Teddy R. Payne Sent: Thursday, May 07, 2009 1:39 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] Encrypting URL Parameters Yeah, I would have to agree that something like a UUID is all that is necessary. It sounds like you just need a unique identifier that does not show the email address, but associates to an email address in your persistence layer. Subscribe: A logical path looking like you have a web interface for a user to enter their email to subscribe to a service. Unsubscribe: The user doesn't want your service notifications anymore and asks to be unsubscribed. You create a UUID in your persistence that links to the email. (You could overwrite this UUID for every request for unsubscribe) The user gets a link that shows a UUID for them. A possible consideration you might look at in your business rules may be that if they ask for an unsubscribe, is there a time limit associated? Can they unsubscribe anytime that they click the link even if it is 10 months ago? If that is fine, you need not worry about tracking a time. Otherwise, you may want to track when the last time an unsubscribe was sent to them. Teddy R. Payne, ACCFD Google Talk - teddyrpa...@gmail.com On Thu, May 7, 2009 at 12:52 PM, John Mason <ma...@fusionlink.com> wrote: For example, a simple UUID would do the trick here. John Howard Fore wrote: What's the goal here? If you want to make sure that spambots can't harvest that email address, you don't want to do Base64 on it as that's not encryption and since it doesn't require a key to decode, you really haven't protected anything. Can you tackle it a different way than exposing the email address? Is there a different unique identifier you can use? You wouldn't need to jump through the hoops with encryption/decryption to keep the address safe. -- Howard Fore, howard.f...@hofo.com <mailto:howard.f...@hofo.com> "The universe tends toward maximum irony. Don't push it." - Jeff Atwood On Thu, May 7, 2009 at 10:42 AM, Clarke Bishop <cbis...@resultantsys.com <mailto:cbis...@resultantsys.com>> wrote: I am building an eMail unsubscribe function, and I thought it would be a good idea to encrypt the eMail address. In the email, I set the unsubscribe link to: unsubscribe.cfm?id= l5N6axdBQlGDpyAklnmkjP+mfaauBKvfS9G9RzUQRJI= But, this string isn’t URLEncoded, so I encoded it like this: unsubscribe.cfm?id=l5N6axdBQlGDpyAklnmkjP%2BmfaauBKvfS9G9RzUQRJI%3D But, I’ve still got a problem because when I URLDecode the parameter, it alters the string. Instead of: l5N6axdBQlGDpyAklnmkjP+mfaauBKvfS9G9RzUQRJI= I get: l5N6axdBQlGDpyAklnmkjP mfaauBKvfS9G9RzUQRJI= It’s changing the “+” to a space. As a result, my decrypt fails. My question is: *What’s the best way to generally handle this requirement?* I know I could just replace the space with a “+”, but I’m expecting there may be other characters that don’t get handled correctly. And, I don’t want to get a bunch of unexpected errors. I’m using ColdFusion 8 and doing the encrypt like this: encrypt(ARGUMENTS.data, variables.theKey, "DESEDE", "Base64") Is there a better encryption or encoding to use? Or, is there a better way to use URLEncode and URLDecode? Thanks for any ideas! Clarke ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink <http://www.fusionlink.com> ------------------------------------------------------------- ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com ------------------------------------------------------------- ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------
