• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

generating lock cookie

 
Amardeep Cheema
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
I am generating the lock cookie value by simply incrementing a private static member variable within a synchronized block. I think this is sufficient because locks are not persistent.
But then I noticed several people discussing other techniques like using random number generators and timestamps to guarantee uniqueness.
I don't see the need for this, but I am worried that I may be about to fall into an elephant trap. Is there an issue I have overlooked?
Thanks,
Deep
PS Fantastic job by all on this forum - I started on the assignment about a month ago and it makes the research (almost) a pleasure.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Deep,
Welcome to JavaRanch.
The issue is that using an incrementing number is less secure than using a random number.
The assignment does not have any requirements about securing your system against malicious programmers, however it is generally a good idea to consider security in anything you design.
PS Fantastic job by all on this forum - I started on the assignment about a month ago and it makes the research (almost) a pleasure.

Then you are not doing enough research - you should be able to find equal amounts of posts arguing both for and against whatever design you decide on. Enough to keep you second guessing yourself for months!
Regards, Andrew
 
Amardeep Cheema
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Andrew. Interesting point. It's something I had not considered. I have to think about whether it makes sense to plug this particular hole in the context of the rest of my design.
(...) you should be able to find equal amounts of posts arguing both for and against whatever design you decide on.

That's the best part. I am spending much more time than I had expected thinking thru design issues because there are so many different possibilities given the specs. I am really learning a lot.
Cheers, Deep
 
Amardeep Cheema
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Do you think we should also avoid exposing any public synchronized methods on server side (public method in a public class) to avoid the possibility of a malicious client grabbing an object lock indefinitely?
The problem is that I don't want to make a partial or misguided effort at security, but at the same time, leaving wide open holes in other areas. Obviously, I don't even want to think about making the application "secure" in any serous way, but I don't know what would constitute a reasonable effort for the purpose of this project.
Any guidance on scope welcome.
Deep
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Deep,
Do you think we should also avoid exposing any public synchronized methods on server side (public method in a public class) to avoid the possibility of a malicious client grabbing an object lock indefinitely?

I presume you are talking about someone writing a program which directly interacts with classes that you did not intend for clients to use.
I don't think we should worry about this. For someone to exploit such code, they would have to have access to the server itself (be able to read and write files), they would have to have access to your API documentation (or make reasonable guesses about what your methods do / decompile your classes), and would have to be able to start a process on the server. If they can do all that, then I don't think a little thing like changing the access modifier on methods and/or classes will really stop them from doing damage.
Alteratively, you could be asking whether we should be exposing the lock() method (and others) via the RMI or sockets connection. In which case we have discussed this a lot in the thread: "Should lock methods be callable by the client". I don't think anyone has discussed that from a security perspective yet - you could be the first
Regards, Andrew
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Alteratively, you could be asking whether we should be exposing the lock() method (and others) via the RMI or sockets connection. In which case we have discussed this a lot in the thread: "Should lock methods be callable by the client".

All that energy spent to buy one more 2-tiers vote ?! That's a bit pathetic, Andrew, and quite unfair for the 3-tiers supporters.

Best,
Phil.
 
Amardeep Cheema
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
After reading the instructions I had immediately and automatically interpreted them to mean a 2-tier design - a fat gui client containing business logic on one machine connecting to a database server on the other. I see no problem with exposing the lock mechanism to the client. I think the lock mechanism gives the writer of the fat client (sorry, I am trying to avoid saying fat client writer) a way to to create atomic units-of-work spanning several records and (potentially) files. Directly analogous to the standard commit-rollback mechanism for transaction control. Others have already clearly and elegantly presented the same arguments.
However, after reading some of the threads and the arguments for the 3-tier solution, I went back to re-examine all my automatic assumptions and re-read the instructions. I think now that the spec can be interpreted to allow business logic to be distributed across both the gui client and on the server. I hesitate to call it a 3-tier solution because that implies a clean separation between the business logic layer and the persistence layer (eg HTML - java business logic - SQL RDBMS), in which case you are back to the same question of what API does the persistence layer expose to the business layer. So I see the problem as either writing a fat business server (as Andrew calls it) which incorporates business logic and physical IO or a fat gui with a general purpose DB server.
I guess it is up to you to decide how you want to distribute your business logic across the client and the server, and I think (I hope) it is not critical for pass/fail which approach you take.
I have personally decided to stick to my original 2-tier approach because I want to write a more general purpose database server providing (that word again) relatively low-level persistence services to the business model sitting in the fat client.
So, sorry Phil, but I am already in the 2-tier camp. But then again, after a couple of days further chasing my tail, who knows...
Greetings from Z�rich.
Deep
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(...) gives the writer of the fat client (sorry, I am trying to avoid saying fat client writer) a way to (...)

Excellent !
I guess it is up to you to decide how you want to distribute your business logic across the client and the server, and I think (I hope) it is not critical for pass/fail which approach you take.

Yes, and it seems that it's the generally-accepted conclusion of that thread. Now I am just thinking to one more argument, based on the instructions, which is in favour of the 3-tiers solution. But I'll post it in the right thread.
Best,
Phil.
[ October 10, 2003: Message edited by: Philippe Maquet ]
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
All that energy spent to buy one more 2-tiers vote ?!
Well, the souls of you confirmed 3-tier advocates may be irredeemably lost, but through perseverence we may yet save a few newly-arrived innocents from your corrupting influence.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Phil,
All that energy spent to buy one more 2-tiers vote ?! That's a bit pathetic, Andrew, and quite unfair for the 3-tiers supporters.


Hey, anyone I can get to help me argue about what is Right and Wrong is a good thing. Hmmm - should we invite Joe in
Is it time for a recount yet? Are 2-tier people in the lead yet?
Regards, Andrew
 
Philippe Maquet
Bartender
Posts: 1872
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
BTW who's Joe ?
[ October 10, 2003: Message edited by: Philippe Maquet ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic