• 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

can recNo be use as cookie value?

 
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi all,
i am taking the B&C 2.2.1,and my DbAccess interface contains some methods require a long coolieValue as argument.so ,i want to use the record's row number as this cookieValue.because one record can be fetched by one client at a time,and one record's row number is exclusive in a db file.so one record's row number which get by client is also exclusive to one db file.
does this way work well?
any comments is grateful!
 
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Joe,

This sounds like a bad idea to me. You don't want one client unlocking a record locked by another client or deleting or updating a record for which it does not have the lock. The cookie is used as proof that the client owns the lock. If you make the cookie equal to the record number, any client can pretend it owns the lock.

Of course it is possible to do it like this, but I think that it is going to cost you considerable points.

Frans.
 
joe lin
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi Frans,
thanks for your reply!
in my opinion,i don't think the cookieValue is used for security.
i think the cookieValue is only use for synchronize.so,as long as the cookieValue can perform the synchronized function well,it is enough!
do you think right?
 
Frans Janssen
Ranch Hand
Posts: 357
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by joe lin:
in my opinion,i don't think the cookieValue is used for security.
i think the cookieValue is only use for synchronize.so,as long as the cookieValue can perform the synchronized function well,it is enough!
do you think right?



Hi Joe,

I have to disagree with you here. The cookie is used for the locking behavior. Imagine that the following happens:

  • client X locks record 12 and gets cookie "12"
  • client X reads record 12 and sees that it is not booked yet.
  • client X updates record 12. It must pass the cookie as proof that it is the lock owner -> record 12 is now booked by client X.
  • client Y comes in. It does not bother about locking.
  • client Y updates record 12. It passes "12" in the cookie parameter, because it knows that the cookie is equal to the record number.
  • record 12 is now illegally booked by client Y.


  • Of course if you assume that all your clients behave nicely (unlike client Y in my example), it is not an issue. But the whole purpose of locking is security, so I think you should prevent that clients abuse the system too easily.

    Frans.
     
    Ranch Hand
    Posts: 119
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    The purpose of a cookie value is to identify the client who owns the lock to a certain record. Due to this reason, the cookie must not be easy to guess. Imagine this. If you make the cookie value equal to the record number, then there is no security already, since a client who does not own the lock can simply supply the record number to the unlock method, and hey presto, the lock is freed! Absolutely no security here!

    One common way is to use the Random class to generate a random long value. That is good enough, since the chances of 2 clients getting the same cookie value is way too remote to worry about (of course, you can check for collisions if you want to, no problem at all).
     
    Don't get me started about those stupid light bulbs.
    reply
      Bookmark Topic Watch Topic
    • New Topic