aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes locked cookie Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "locked cookie" Watch "locked cookie" New topic
Author

locked cookie

Payal Shah
Ranch Hand

Joined: Jul 10, 2006
Posts: 67
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
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2265
    
    3

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


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Payal Shah
Ranch Hand

Joined: Jul 10, 2006
Posts: 67
cool.. I will do that same.. I like your way b/c that makes it more unique.

Thank you.
Tomasz Sochanski
Ranch Hand

Joined: Jan 13, 2009
Posts: 47

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

Joined: Dec 28, 2007
Posts: 2265
    
    3

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

Joined: Jan 13, 2009
Posts: 47

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

Joined: Dec 28, 2007
Posts: 2265
    
    3

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

Joined: Jan 13, 2009
Posts: 47

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

Joined: Dec 28, 2007
Posts: 2265
    
    3

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.
Andrew Monkhouse
author and jackaroo
Marshal Commander

Joined: Mar 28, 2003
Posts: 11460
    
  94

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


The Sun Certified Java Developer Exam with J2SE 5: paper version from Amazon, PDF from Apress, Online reference: Books 24x7 Personal blog
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: locked cookie