One word of caution about using UUID's on Windows, there is a limitation to how 
quickly the JVM can generate them. It has something to do with the use of the 
system clock and it an actual hard limit. On CFMX and CF7, you could very 
easily crash the server if you try to crank them out too fast. CF8 seems to be 
more resilient. Not sure if they put a delay around their wrapper of the Java 
methods to do UUID's, but 8 just works better for the.  Found out about this 
the hard way with the "infusion calendar". Whomever developed that app had a 
overaggresive desire to be "OO" and totally misused UUID's all over the place. 
It resulted in great angst for us, so be careful... I'm not saying to not use 
them, because I use them all the time. Just be aware of the limitation. 




________________________________
From: Cameron Childress <camer...@gmail.com>
To: discussion@acfug.org
Sent: Friday, May 8, 2009 10:21:25 AM
Subject: Re: [ACFUG Discuss] Encrypting URL Parameters

They are talking about the 35 char strings created by the createUUID()
function in CF.  They are 32 chars with 3 dashes and it stand for
"Universally Unique ID".  The string generated by createUUID() will
not only be unique no the server, but across all CF servers.

It's a nice clean ID that will not be random, but should still be
difficult enough to guess that it will keep casual fiddlers away from
it.  Someone who wanted to spend a little time predicting UUIDs
probably could, but I'm not sure your use case warrants this level of
paranoia.

In this case though, it will work more cleanly in a URL, particularly
if you strip the dashes out of it.  Some people even use these ak PKs
in database tables instead of ID numbers since you can generate them
across multiple systems without worrying about what they next PK ID
number might be.

As far as using the email address vs and ID, you could always use some
SQL to get that ID's corresponding email and use that to check for it
in other locations.

Having said all that, it looks like you are far enough down the path
of using the email address that it may not be worthwhile to switch.  I
think both solutions are perfectly acceptable.

-Cameron

On Thu, May 7, 2009 at 6:37 PM, Clarke Bishop <cbis...@resultantsys.com> wrote:
> 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 FusionLink
> -------------------------------------------------------------



-- 
Cameron Childress
Sumo Consulting Inc
http://www.sumoc.com
---
cell:  678.637.5072
aim:   cameroncf
email: camer...@gmail.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

-------------------------------------------------------------


Reply via email to