RE: [ACFUG Discuss] Encrypting URL Parameters

[Shane]

Hear Hear.
 
You mean we should build what is best for the client, that we should solve
the overall business problem in the most efficient manner, rather than
building code as art?  What a concept!
 
Some applications cry for abstraction and objects.  Others, do not need
them.  And you should always code (and comment) for readability for the next
developer - not for what some define as elegance - like 12 nested functions.
 
OK - back to my cave now.
 
Shane Heasley
CTek-Media.com

  _  

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of shawn gorrell
Sent: Friday, May 08, 2009 10:01 AM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Encrypting URL Parameters


You got it. Basically a way of giving each instance a unique number. For
what reason? I have no idea. Much better ways to accomplish exactly the same
thing. The app came out shortly after CFC's came about, so I think there was
some irrational exuberance about objects in play. Some people have gotten
over that mindset, and others have gotten even worse. Sometimes I long for
the days when CF was actually simple. There are people in the community that
are trying to make it as complex as Java. When CF reaches that point, I'll
just quit doing it and write Java code instead. Why deal with a middle man
if the coding is going to be equally hard? This isn't me ranting about a
desire to get rid of CFC's, far from it, but I do think that not everything
has to be an object and not everything needs to be some pristine example of
OO genius. I find "necessary complexity" (meaning simplicity) to be far more
elegant. 


  _  

From: Cameron Childress 
To: discussion@acfug.org
Sent: Friday, May 8, 2009 10:53:02 AM
Subject: Re: [ACFUG Discuss] Encrypting URL Parameters

I'll take your word on it.  Let me guess - they are generating a UUID
in the init() of every CFC, and instantiating a new CFC for each day,
week, month, and event - and more.

-Cameron

On Fri, May 8, 2009 at 10:36 AM, shawn gorrell  wrote:
> 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.

-- 
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 <http://www.fusionlink.com>  
- 

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.0.238 / Virus Database: 270.12.21/2103 - Release Date: 05/08/09
11:43:00





-
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
-

Re: [ACFUG Discuss] Encrypting URL Parameters

[John Mason]

Fun stuff. Yep the createUUID is expensive specially on older jvm's. 1.6 
family which CF8 runs on is better. It is, I believe a single threaded 
operation at it's core, due to the fact it needs a time stamp to avoid 
repeats. I read a blog post recently that had similar problems with uuid 
but with cftokens - 
http://www.webapper.com/blog/index.php/2009/05/05/createuuid_friendly_function_or_server_killer/


It's funny because we were talking about over abstracting at the last 
meeting. OO is great but developers can take things too far.


John
ma...@fusionlink.com



shawn gorrell wrote:
You got it. Basically a way of giving each instance a unique number. 
For what reason? I have no idea. Much better ways to accomplish 
exactly the same thing. The app came out shortly after CFC's came 
about, so I think there was some irrational exuberance about objects 
in play. Some people have gotten over that mindset, and others have 
gotten even worse. Sometimes I long for the days when CF was actually 
simple. There are people in the community that are trying to make it 
as complex as Java. When CF reaches that point, I'll just quit doing 
it and write Java code instead. Why deal with a middle man if the 
coding is going to be equally hard? This isn't me ranting about a 
desire to get rid of CFC's, far from it, but I do think that not 
everything has to be an object and not everything needs to be some 
pristine example of OO genius. I find "necessary complexity" (meaning 
simplicity) to be far more elegant.



*From:* Cameron Childress 
*To:* discussion@acfug.org
*Sent:* Friday, May 8, 2009 10:53:02 AM
*Subject:* Re: [ACFUG Discuss] Encrypting URL Parameters

I'll take your word on it.  Let me guess - they are generating a UUID
in the init() of every CFC, and instantiating a new CFC for each day,
week, month, and event - and more.

-Cameron

On Fri, May 8, 2009 at 10:36 AM, shawn gorrell <mailto:chees...@yahoo.com>> wrote:
> 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.

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

Re: [ACFUG Discuss] Encrypting URL Parameters

[Teddy R. Payne]

lol, I need to create a teddy.cfc =) bob.cfc sounds just as good.


Teddy R. Payne, ACCFD
Google Talk - teddyrpa...@gmail.com



On Fri, May 8, 2009 at 11:14 AM, shawn gorrell  wrote:

> There are other ways to generate unique ids. You could give them names like
> Chad, or Bob, or Steve, or even Teddy. Skip the UUID and make it more
> personal.
>
> --
> *From:* Teddy R. Payne 
> *To:* discussion@acfug.org
> *Sent:* Friday, May 8, 2009 11:10:40 AM
> *Subject:* Re: [ACFUG Discuss] Encrypting URL Parameters
>
> Giving a unique ID to an object is like trying to replicate the
> functionality or base premise of Hibernate if you are using it to track
> state of the object's store.
>
>
>
> -
> 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>
> -
>

Re: [ACFUG Discuss] Encrypting URL Parameters

[shawn gorrell]

There are other ways to generate unique ids. You could give them names like 
Chad, or Bob, or Steve, or even Teddy. Skip the UUID and make it more personal. 





From: Teddy R. Payne 
To: discussion@acfug.org
Sent: Friday, May 8, 2009 11:10:40 AM
Subject: Re: [ACFUG Discuss] Encrypting URL Parameters

Giving a unique ID to an object is like trying to replicate the functionality 
or base premise of Hibernate if you are using it to track state of the object's 
store.


-
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
-

Re: [ACFUG Discuss] Encrypting URL Parameters

[Cameron Childress]

Using a UUID as an object identifier has often been promoted as a way
to compare two objects to see if they are the same.  About halfway
down the page:

http://www.adobe.com/devnet/coldfusion/articles/oo_coldfusion.html
"To test for equality of two objects, you need a way of providing
objects with their own, unique identity. A UUID would be a good
solution. Many languages have the concept of object identity;
ColdFusion does not, but you can add this in quite easily by modifying
component.cfc."

Of course, this has other unintended consequences, such as the one you
are describing.

-Cameron

On Fri, May 8, 2009 at 11:01 AM, shawn gorrell  wrote:
> You got it. Basically a way of giving each instance a unique number. For
> what reason? I have no idea. Much better ways to accomplish exactly the same
> thing. The app came out shortly after CFC's came about, so I think there was
> some irrational exuberance about objects in play. Some people have gotten
> over that mindset, and others have gotten even worse. Sometimes I long for
> the days when CF was actually simple. There are people in the community that
> are trying to make it as complex as Java. When CF reaches that point, I'll
> just quit doing it and write Java code instead. Why deal with a middle man
> if the coding is going to be equally hard? This isn't me ranting about a
> desire to get rid of CFC's, far from it, but I do think that not everything
> has to be an object and not everything needs to be some pristine example of
> OO genius. I find "necessary complexity" (meaning simplicity) to be far more
> elegant.
>
> 
> From: Cameron Childress 
> To: discussion@acfug.org
> Sent: Friday, May 8, 2009 10:53:02 AM
> Subject: Re: [ACFUG Discuss] Encrypting URL Parameters
>
> I'll take your word on it.  Let me guess - they are generating a UUID
> in the init() of every CFC, and instantiating a new CFC for each day,
> week, month, and event - and more.
>
> -Cameron
>
> On Fri, May 8, 2009 at 10:36 AM, shawn gorrell  wrote:
>> 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.
>
> --
> 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
-

Re: [ACFUG Discuss] Encrypting URL Parameters

[Teddy R. Payne]

Giving a unique ID to an object is like trying to replicate the
functionality or base premise of Hibernate if you are using it to track
state of the object's store.

Re: [ACFUG Discuss] Encrypting URL Parameters

[shawn gorrell]

You got it. Basically a way of giving each instance a unique number. For what 
reason? I have no idea. Much better ways to accomplish exactly the same thing. 
The app came out shortly after CFC's came about, so I think there was some 
irrational exuberance about objects in play. Some people have gotten over that 
mindset, and others have gotten even worse. Sometimes I long for the days when 
CF was actually simple. There are people in the community that are trying to 
make it as complex as Java. When CF reaches that point, I'll just quit doing it 
and write Java code instead. Why deal with a middle man if the coding is going 
to be equally hard? This isn't me ranting about a desire to get rid of CFC's, 
far from it, but I do think that not everything has to be an object and not 
everything needs to be some pristine example of OO genius. I find "necessary 
complexity" (meaning simplicity) to be far more elegant. 





From: Cameron Childress 
To: discussion@acfug.org
Sent: Friday, May 8, 2009 10:53:02 AM
Subject: Re: [ACFUG Discuss] Encrypting URL Parameters

I'll take your word on it.  Let me guess - they are generating a UUID
in the init() of every CFC, and instantiating a new CFC for each day,
week, month, and event - and more.

-Cameron

On Fri, May 8, 2009 at 10:36 AM, shawn gorrell  wrote:
> 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.

-- 
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
-

Re: [ACFUG Discuss] Encrypting URL Parameters

[Cameron Childress]

I'll take your word on it.  Let me guess - they are generating a UUID
in the init() of every CFC, and instantiating a new CFC for each day,
week, month, and event - and more.

-Cameron

On Fri, May 8, 2009 at 10:36 AM, shawn gorrell  wrote:
> 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.

-- 
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
-

Re: [ACFUG Discuss] Encrypting URL Parameters

[shawn gorrell]

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 
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  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 
> 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 
> 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

Re: [ACFUG Discuss] Encrypting URL Parameters

[Cameron Childress]

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  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 
> 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 
> 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.
>> 

Re: [ACFUG Discuss] Encrypting URL Parameters

[shawn gorrell]

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 
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  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  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 

Re: [ACFUG Discuss] Encrypting URL Parameters

[Cameron Childress]

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  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  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  <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: l5N6

RE: [ACFUG Discuss] Encrypting URL Parameters

[Clarke Bishop]

Thanks Charlie! I’m doing exactly what you said: 
URLEncodedFormat(encrypt(string,key)).

 

The problem was that my encrypted string has a “+” in it, but URLDecode 
translated that to a space. Then, the decrypt failed!

 

But, good suggestion on the try/catch. I probably wouldn’t have thought about 
it. Thanks!

 

   Clarke

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Charlie Arehart
Sent: Thursday, May 07, 2009 1:40 PM
To: discussion@acfug.org
Subject: RE: [ACFUG Discuss] Encrypting URL Parameters

 

Clarke, besides considering the other useful suggestions about whether it’s 
appropriate to even try those, or if there may be alternatives, I’ll say that 
I’ve done it before for other reasons, with code like this (where string was 
what needed to be encrypted, and key was the key for encoding/decoding):

 

?code=#urlencodedformat(encrypt(string,key))#

 

I then was able to get the result with 

 

That worked for me, but perhaps there are aspects of the string you’re 
encrypting/encoding that I wasn’t hitting. Still, since you didn’t offer code, 
we can’t know if you’re doing the encrypt inside the encode, or vice-versa.

 

I’ll add as well that if someone messes with the code then the decrypt will of 
course fail, causing an error, so you want to try/catch this.

 

/charlie

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Clarke Bishop
Sent: Thursday, May 07, 2009 10:42 AM
To: discussion@acfug.org
Subject: [ACFUG Discuss] Encrypting URL Parameters

 

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 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

-

RE: [ACFUG Discuss] Encrypting URL Parameters

[Clarke Bishop]

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  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 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.edituserfo

RE: [ACFUG Discuss] Encrypting URL Parameters

[Clarke Bishop]

Thanks Jeremy! I think the Hex encoding for the encrypt functions is exactly
what I was looking for.

 

   Clarke

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Jeremy Bruck
Sent: Thursday, May 07, 2009 11:28 AM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] Encrypting URL Parameters

 

Clark,

 

Yes, you could use the "hidden/secret/unpublished" tag (cfusion_encrypt and
cfusion_decrypt) which the CF Administrator uses to make it URL compatible
but if you change app servers (BD or Railo) or if they kill it you will be
screwed.

 

The best way we have found to do this is to use a HEX encoding instead which
is fully URL compatible.  We used base64 like you did at first and ran into
challenges long term.  The algorithm we use is AES with the Hex encoding.
Yes it is a touch longer when compared to base64 but you never have to worry
about dealing with special characters.  Below is an example of our code that
we use:

 

encrypt(encryptedData, application.HexEncryptString, 'AES', 'HEX');

 

This generates code that looks like this:  EE86208453404F3EC5E3BCFBDBBA2FA5

 

FYI, to create a compatible AES Encrypt String use the following



 

If you are using base64 now you can create a single function and test for
the HEX format and decrypt with it if passes and if not decrypt with base64.
Here is the test code:

 

 

 

Only thing I am not sure about is if AES is available in the std version of
CF or purely enterprise.  We have been using Railo lots and it is there.

 

Regards,

Jeremy

 

--

Strategic Growth Services, LLC

Jeremy Bruck

jbr...@growstrategy.com

770-953-8643 x103

 

 

 

On May 7, 2009, at 10:42 AM, Clarke Bishop 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
-

RE: [ACFUG Discuss] Encrypting URL Parameters

[Charlie Arehart]

Clarke, besides considering the other useful suggestions about whether it’s 
appropriate to even try those, or if there may be alternatives, I’ll say that 
I’ve done it before for other reasons, with code like this (where string was 
what needed to be encrypted, and key was the key for encoding/decoding):

 

?code=#urlencodedformat(encrypt(string,key))#

 

I then was able to get the result with 

 

That worked for me, but perhaps there are aspects of the string you’re 
encrypting/encoding that I wasn’t hitting. Still, since you didn’t offer code, 
we can’t know if you’re doing the encrypt inside the encode, or vice-versa.

 

I’ll add as well that if someone messes with the code then the decrypt will of 
course fail, causing an error, so you want to try/catch this.

 

/charlie

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Clarke Bishop
Sent: Thursday, May 07, 2009 10:42 AM
To: discussion@acfug.org
Subject: [ACFUG Discuss] Encrypting URL Parameters

 

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   
- 




-

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

-

Re: [ACFUG Discuss] Encrypting URL Parameters

[Teddy R. Payne]

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  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 
>> "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>> 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 
>>-
>>
>>
>
>
> -
> 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
> -
>
>
>
>

Re: [ACFUG Discuss] Encrypting URL Parameters

[John Mason]

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 
"The universe tends toward maximum irony. Don't push it." - Jeff Atwood


On Thu, May 7, 2009 at 10:42 AM, Clarke Bishop 
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 
- 







-
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
-

Re: [ACFUG Discuss] Encrypting URL Parameters

[Howard Fore]

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
"The universe tends toward maximum irony. Don't push it." - Jeff Atwood


On Thu, May 7, 2009 at 10:42 AM, Clarke Bishop 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 
> -

Re: [ACFUG Discuss] Encrypting URL Parameters

[Jeremy Bruck]

Clark,

Yes, you could use the "hidden/secret/unpublished" tag  
(cfusion_encrypt and cfusion_decrypt) which the CF Administrator uses  
to make it URL compatible but if you change app servers (BD or Railo)  
or if they kill it you will be screwed.


The best way we have found to do this is to use a HEX encoding instead  
which is fully URL compatible.  We used base64 like you did at first  
and ran into challenges long term.  The algorithm we use is AES with  
the Hex encoding.  Yes it is a touch longer when compared to base64  
but you never have to worry about dealing with special characters.   
Below is an example of our code that we use:


encrypt(encryptedData, application.HexEncryptString, 'AES', 'HEX');

This generates code that looks like this:   
EE86208453404F3EC5E3BCFBDBBA2FA5


FYI, to create a compatible AES Encrypt String use the following


If you are using base64 now you can create a single function and test  
for the HEX format and decrypt with it if passes and if not decrypt  
with base64.  Here is the test code:


 


Only thing I am not sure about is if AES is available in the std  
version of CF or purely enterprise.  We have been using Railo lots and  
it is there.


Regards,
Jeremy

--
Strategic Growth Services, LLC
Jeremy Bruck
jbr...@growstrategy.com
770-953-8643 x103



On May 7, 2009, at 10:42 AM, Clarke Bishop 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
-