• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

SecurityException: Assignment constraints unclear!

 
Charles Ohene
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi out there. My assignment says the following about DB.unock():
"Cookie must be the cookie returned when the record was locked, otherwise throws SecurityException."
Ok, but what if the specified record is not locked at all? Then there is NO cookie ever returned and unlock() has nothing to do! Shall I throw the SecException anyway? Or shall I only throw it if the record is definitly locked, but with an other cookie?

Thx for your help, I don't want to run in automatic failure.
 
Ali Hussain
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Charles Ohene:
Ok, but what if the specified record is not locked at all? Then there is NO cookie ever returned and unlock() has nothing to do! Shall I throw the SecException anyway? Or shall I only throw it if the record is definitly locked, but with an other cookie?

Thx for your help, I don't want to run in automatic failure.

I guess we can just ignore the request i.e. dont do anything. A client wants to unlock a record, and if it is already unlocked then we have fulfilled the client's request. I dont plan to do anything in my implementation (just document this in Javadoc) unless my fellow ranchers have other opinions.
 
Charles Ohene
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thx for the fast reply. I ignore the SecException too, if the record is not locked at all... But if someone like to corrupt our design by using a malicious client (internet feature in future iteration), then it would be realized earlier if each unlock-attempt leads to a SecurityException, even if the record is actually not locked.
Hmm... maybe only logging is not enough here (thats what I do!) ? Or is this thought to far from the spec?
 
Ali Hussain
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Charles Ohene:
Thx for the fast reply. I ignore the SecException too, if the record is not locked at all... But if someone like to corrupt our design by using a malicious client (internet feature in future iteration), then it would be realized earlier if each unlock-attempt leads to a SecurityException, even if the record is actually not locked.
Hmm... maybe only logging is not enough here (thats what I do!) ? Or is this thought to far from the spec?

Sorry but I can not see how a malicious client can misuse the unlock method, if the unlock method does not do anything with his request (if the given record is not locked). Can you please elaborate?
[ December 28, 2005: Message edited by: Ali Hussain ]
 
Charles Ohene
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think u are right. There is no danger in it.
Thx
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic