Nothing to do with security measures for me. Many times I simply don't want
anyone accessing another record in the database. I am sure that you can
imagine that type of scenario, in case not
An example would be for an emailed order confirmation with a link back to
their order
(in this case the client does not want someone to fill
out user details and create an account for their own reasons) By using an
integer it would be extremely easy for someone to view other order details
Doesn't require a UUID as the PK, just something unique and unpredictable for
that piece
On Fri, Jun 12, 2009 at 9:59 AM, Dave Watts wrote:
An example would be for an emailed order confirmation with a link back to
their order details.(in this case the client does not want someone to fill
out user details and create an account for their own reasons) By using an
integer it would
On Friday 12 Jun 2009, Ryan Letulle wrote:
An example would be for an emailed order confirmation with a link back to
their order details. ... By using an
integer it would be extremely easy for someone to view other order details
but not so with a uuid.
But surely your getOrderFromOrderId()
Are you guys saying that I should force my client to require their client to
create a user account? Or am I missing something here in the symantics.
Because I don't see another solution.
BTW I am not talking about guarding Fort Knox here.
--
Ryan LeTulle
On Fri, Jun 12, 2009 at 4:21 AM,
Doesn't require a UUID as the PK, just something unique and unpredictable
for that piece of functionality, which could be derived/hashed from any
static column(s).
Peter,
Are you saying that a uuid is inherently insecure? I thought part of the
uuid was created randomly and for the purposes
On Fri, Jun 12, 2009 at 1:38 PM, Ryan Letulle wrote:
Are you saying that a uuid is inherently insecure?
Depends on how you use them.
I thought part of the
uuid was created randomly and for the purposes where I was using it felt
comfortable.
Some UUIDs are random, some are completely
OK, I guess. :)
--
Ryan LeTulle
On Fri, Jun 12, 2009 at 7:01 AM, Jochem van Dieten joch...@gmail.comwrote:
On Fri, Jun 12, 2009 at 1:38 PM, Ryan Letulle wrote:
Are you saying that a uuid is inherently insecure?
Depends on how you use them.
I thought part of the
uuid was created
Are you saying that a uuid is inherently insecure?
UUIDs are guaranteed to be unique, but not (afaik) to be unpredictable.
I don't know *how* predictable they might be, but for any secure string I
wouldn't want to rely entirely on something with potentially knowable/guessable
sources - I
Thank you all.
A long habit of not thinking a thing wrong gives it a superficial appearance
of being right.
Thomas Painehttp://www.brainyquote.com/quotes/quotes/t/thomaspain161749.html
*
*--
Ryan LeTulle
On Fri, Jun 12, 2009 at 7:12 AM, Peter Boughton bought...@gmail.com wrote:
Are you
values that
is)
.:.:.:.:.:.:.:.:.:.:.
Bobby Hartsfield
http://acoderslife.com
http://cf4em.com
-Original Message-
From: Peter Boughton [mailto:bought...@gmail.com]
Sent: Friday, June 12, 2009 8:13 AM
To: cf-talk
Subject: Re: Product ID - enterprise level application
Are you saying
Are you guys saying that I should force my client to require their client to
create a user account? Or am I missing something here in the symantics.
Because I don't see another solution.
If they want to view order history, yes, that's the easiest way to ensure
security for viewing the
One note I don't use the uuid as the primary key in these instances. I know
that's how this post started. :)
--
Ryan LeTulle
On Fri, Jun 12, 2009 at 9:07 AM, Mary Jo Sminkey mary...@cfwebstore.comwrote:
Are you guys saying that I should force my client to require their client
to
create a
I am wondering the best way to create an ID for an online advertising site that
I anticipate could have about a million products uploaded a day.
I had considered using create UUID I read the following from Christian Cantrell
If you want the convenience of generating your own primary key
The tradeoff will be between a user not being able to play around with the
querystring (i.e change id=1 to id=2) and performance. How much performance
I can't say. A million a day I would think you would start to see it.
I personally haven't hit the performance issue with uuid but I also
Eventually integers do get too large for the database field. If you're
truly adding a million new IDs / day, that could happen. There's a fairly
modest upper limit to 'int', so definitely look at 'bigint' (SQL Server) to
handle integer IDs if you take that route.
The tradeoff will be between a user not being able to play around with the
querystring (i.e change id=1 to id=2)
Huh!?
Please tell me you don't use UUIDs as an alternative to having proper
security/permissions in place?
Because if you do have proper security there is no playing around that
Nothing to do with security measures for me. Many times I simply don't want
anyone accessing another record in the database. I am sure that you can
imagine that type of scenario, in case not
An example would be for an emailed order confirmation with a link back to
their order details.(in
18 matches
Mail list logo
