Download the open source version of CalendarInfusion and try it out. You'd be surprised how easy it is to crush a CF7 server if you have a calendar with a ton of events and just a little bit of traffic.
________________________________ From: Cameron Childress <camer...@gmail.com> To: discussion@acfug.org Sent: Friday, May 8, 2009 10:33:56 AM Subject: Re: [ACFUG Discuss] Encrypting URL Parameters Yes, I've heard this too. I have a feeling you have to really be giving the UUID engine a workout for this to happen though. I seem to also remember there is a slight performance hit for generating them, but it should be negligible unless you are generating 10K a second or some really insane number of UUIDs. -Cameron On Fri, May 8, 2009 at 10:29 AM, shawn gorrell <chees...@yahoo.com> wrote: > 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 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 -------------------------------------------------------------
