[Tickets #7931] Re: Left Logout button throws "malicious request"

[bugs at horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/7931
------------------------------------------------------------------------------
  Ticket             | 7931
  Updated By         | horde at agotnes.com
  Summary            | Left Logout button throws "malicious request"
  Queue              | Horde Base
  Version            | 3.3.3
  Type               | Bug
  State              | Feedback
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             | Horde Developers
------------------------------------------------------------------------------


horde at agotnes.com (2009-10-21 11:03) wrote:

I've got this rather annoying problem, and was wondering whether or  
not it would be possible to resolve it by locking records during the  
initial reads using SQL in the following manner:

http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html

I'm leaning towards a SHARE lock myself as it allows all reads to  
continue but only the first one to read gets to update, but I've not  
studied when the SQL is issued and whether anything would be blocked  
awaiting a DB lock if something else holds a lock...

I'm not sure what the PEAR DB library fix would be as they don't know  
that an update is imminent unless they're told so by the code using  
their library, which is exactly what the above tries to achieve...

'course, PEAR may have some other method for this already but I'm no  
PEAR expert, indeed, the best solution overall would probably be  
Optimistic locking but that would probably require significant code  
changes or adding another library between Horde and the DB...