Skip Menu |
 

This queue is for tickets about the Class-DBI CPAN distribution.

Report information
The Basics
Id: 6434
Status: open
Priority: 0/
Queue: Class-DBI

People
Owner: Nobody in particular
Requestors: sriha [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: 0.96
Fixed in: (no value)



Subject: LiveObject caching may return results from other DBs when using custom db_Main
Class::DBI 0.96 Perl 5.8.0 RedHat 2.4.21-15.ELsmp Apache 2.0.46 mod_perl 1.99 My mod_perl2 application uses a custom db_Main method to connect to a database based on some information in the URL. The app may be called with, say, db=STORE_1 or db=STORE_2. The %Live_Objects caching introduced in CDB 0.96 uses the class name and primary keys to identify cached objects but does not pay attention to which DB instance the object belongs. Problem: In a persisted environment (mod_perl), if I retrieve an object with ID 123 from the STORE_1 database, it will be cached and subsequent queries for object with ID 123 in the STORE_2 database (or any other database accessed with this class) will return the cached object. This is incorrect behavior and a potential SECURITY HOLE since users of STORE_2 may now see data from STORE_1 without authorization. My Workaround: Use Class::CGI 0.95 which does not exhibit this problem. Solution: You should incorporate the dbh returned by $class->db_Main as part of the key used in identifying LiveObjects.
Download (untitled) / with headers
text/plain 435b
Show quoted text
> Solution: You should incorporate the dbh returned by $class->db_Main > as part of the key used in identifying LiveObjects.
As of 3.0.3 you could supply your own _live_object_key() method which calls SUPER and appends a value based on your $dbi specific information. I'd like to come up with a better way of dealing with this, but I'm not sure how this could be done in a generic enough manner. Any suggestions? Thanks, Tony
From: will [...] spanner.org
[TMTM - Mon Sep 12 07:02:07 2005]: Show quoted text
> > Solution: You should incorporate the dbh returned by $class->db_Main > > as part of the key used in identifying LiveObjects.
> > As of 3.0.3 you could supply your own _live_object_key() method which > calls SUPER and appends a value based on your $dbi specific information. > > I'd like to come up with a better way of dealing with this, but I'm not > sure how this could be done in a generic enough manner.
It is kind of a (very minor) pain, since you can't call SUPER::_live_object_key from outside the package, so this: *{"$class\::_live_object_key"} = sub { my ($me, $data) = @_; return $me->_factory->id . '__' . $me->SUPER::_live_object_key($data); }; is no good and I have to duplicate your key-making code instead. My suggestion would be to expose (but not use) an object method with a name like application_instance(), and change the _live_object_key method to prepend whatever value it returns. People could then use the same method to pick the right database handle, and all the other odd things they seem to want to do. .2p will
Date: Mon, 3 Oct 2005 09:40:03 +0100
From: Tony Bowden <tony [...] kasei.com>
To: via RT <bug-Class-DBI [...] rt.cpan.org>
Subject: Re: [cpan #6434] LiveObject caching may return results from other DBs when using custom db_Main
RT-Send-Cc:
Download (untitled) / with headers
text/plain 968b
On Sun, Oct 02, 2005 at 12:25:50PM -0400, via RT wrote: Show quoted text
> It is kind of a (very minor) pain, since you can't call SUPER::_live_object_key from outside the > package, so this: > > *{"$class\::_live_object_key"} = sub { > my ($me, $data) = @_; > return $me->_factory->id . '__' . $me->SUPER::_live_object_key($data); > }; > is no good and I have to duplicate your key-making code instead.
I don't understand the context here, so I don't really see the problem. Show quoted text
> My suggestion would be to expose (but not use) an object method with a name like > application_instance(), and change the _live_object_key method to prepend whatever value it > returns. People could then use the same method to pick the right database handle, and all > the other odd things they seem to want to do.
I'm working on changing how all this works at the minute, but if I could understand this suggestion better then it might shape what I do :) Thanks, Tony


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.