• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

locked cookie

 
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I cannot decide the value for locked cookie.

I am debating between


I do not know which one to pick. Anyone has commets if they have made above choice and why they made it..

thanks
 
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, any of them works fine. Here's what I did:



This way, no chances 2 clients can have the same id (even though my lock method does not return any value, I came up with an approach where I identify clients with these values).
 
Payal Shah
Ranch Hand
Posts: 67
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
cool.. I will do that same.. I like your way b/c that makes it more unique.

Thank you.
 
Ranch Hand
Posts: 47
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Roberto Perillo wrote:Well, any of them works fine. Here's what I did:



This way, no chances 2 clients can have the same id (even though my lock method does not return any value, I came up with an approach where I identify clients with these values).



I think they still can have the same id. Suppose such a situation: we have two time values: first is 1231834662150 and second is delayed with 1 millisecond and equals 1231834662151. Now if random generator give us two randomized long values 1231834662151 and 1231834662150 we have multiplications that looks like the following:


Both of them results the save value.
 
Roberto Perillo
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It is easier to rain money than this happening!

It is almost impossible to have two clients accessing the server at almost the same time (like in your example), but let's say that happened. They now have to respectively get a random number and the same random number increased by one? For sure it is way easier to win the lottery than this happening!
 
Tomasz Sochanski
Ranch Hand
Posts: 47
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Roberto Perillo wrote:It is easier to rain money than this happening!

It is almost impossible to have two clients accessing the server at almost the same time (like in your example), but let's say that happened. They now have to respectively get a random number and the same random number increased by one? For sure it is way easier to win the lottery than this happening!



That's right. Anyway - access time is not important in my example - it can be 1 millisecond or 10 minutes if we have to make it more likely. In some situations there can be found long (random) value which after your multiplication creates already existing id. But you are absolutely right - it is almost impossible.

The only think I can't understand is the multiplication you use - why is it better (more likely to be unique ?) to multiply timestamp with random long instead of using pure and lonely random long?

 
Roberto Perillo
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This is just to guarantee that no way two clients can get the same ID. As I said, the day two clients get the same ID with the approach I used, it will be the end of the world!
 
Tomasz Sochanski
Ranch Hand
Posts: 47
Eclipse IDE Oracle Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Roberto Perillo wrote:This is just to guarantee that no way two clients can get the same ID. As I said, the day two clients get the same ID with the approach I used, it will be the end of the world!



Sure, but I still can't imagine what is this multiplication with timestamp for. Is it better: then this one:

:?:
 
Roberto Perillo
Bartender
Posts: 2292
3
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Again, it is just an approach I came up with so it is more likely to be unique. If you feel comfortable with new Random().nextLong() or System.currentTimeMillis(), go right ahead.
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Of course there is the danger that you are expending effort writing something that may be more complex and less secure than existing classes and methods (while I don't have the instructions in front of me, I think there is a warning that points can be deducted if you reinvent the wheel). As an example, have you looked at the SecureRandom class (that has existed since JDK 1.4)?

Just as an aside, I recall a few years back someone claimed that security through cookies was error prone, and therefore they verified ownership using other methods, and always returned 0 as the lock cookie. I think they passed too (but their code for ownership and documentation on why they did this must have been good).

Regards, Andrew
 
reply
    Bookmark Topic Watch Topic
  • New Topic