[Devel] [ openser-Bugs-1372451 ] avpops: avp_db_delete deletes too much

[Norman Brandinger]

I'm good with the idea not to mix use_domain(0) and use_domain(1) in the 
same OpenSER instance.  This condition of operation should probably be 
make clear to the user community. 

Until now, I thought that it was possible to mix the two (and scratched 
my head when various bits and pieces of the system didn't operate as 
expected).

Regards,
Norm

Bogdan-Andrei Iancu wrote:
> Hi Norman,
>
> I find the scenario quite dangerous - sharing same DB between two 
> opensers which handles in different ways the information may be very 
> risky....as already proven.
>
> IMHO, I would say the fix should be done by using separate databases.
>
> regards,
> bogdan
>
> Norman Brandinger wrote:
>
>> Unless there is agreement to change the existing behavior, it should 
>> remain the same.  Causes less waves this way :)
>>
>> If that's the case, I would like to suggest that an additional value 
>> be added to use_domain() maybe just for avpops to start.  Something 
>> like modparam("avpops","use_domain", 2) that would perform as 
>> outlined previously.
>>
>> Without this, AVP's "must" belong to an OpenSER instance that "uses 
>> domains" or an OpenSER instance that "dosen't use domains".  There is 
>> no ability to mix the two from a database perspective.
>> In a real world example, you might have two OpenSER's accessing the 
>> same back end database.  If one instance "uses domains" and the other 
>> instance "doesn't use domains" the results for the "doesn't use 
>> domains" instance will be unpredictable.
>> Obviously, two distinct databases or maybe a single database with two 
>> different usr_preferences tables would be a way to "work around" 
>> this.  It seems that a single database, single table is a cleaner way 
>> to solve this problem.
>>
>> You comments are welcome.
>>
>> Norm
>>
>> Bayan William Towfiq wrote:
>>
>>> Yes, I really don't think the usage should change.
>>>
>>> Bayan
>>>
>>> Klaus Darilion wrote:
>>>
>>>> I think that's the intendend usage. AFAIK all modules use only the 
>>>> username (and do not care about the domain) if use_domain=0;
>>>>
>>>> klaus
>>>>
>>>> SourceForge.net wrote:
>>>>
>>>>> Bugs item #1372451, was opened at 2005-12-03 19:26
>>>>> Message generated for change (Tracker Item Submitted) made by Item 
>>>>> Submitter
>>>>> You can respond by visiting: 
>>>>> https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1372451&group_id=139143 
>>>>>
>>>>>
>>>>> Please note that this message will contain a full copy of the 
>>>>> comment thread,
>>>>> including the initial issue submission, for this request,
>>>>> not just the latest update.
>>>>> Category: modules
>>>>> Group: ver devel
>>>>> Status: Open
>>>>> Resolution: None
>>>>> Priority: 5
>>>>> Submitted By: Norman Brandinger (goestelecom)
>>>>> Assigned to: Nobody/Anonymous (nobody)
>>>>> Summary: avpops: avp_db_delete deletes too much
>>>>>
>>>>> Initial Comment:
>>>>> 1) The use_domain parameter is turned off, for example
>>>>> in the statement below:
>>>>>
>>>>> modparam("avpops","use_domain", 0)
>>>>>
>>>>> 2) A call to avp_db_delete is made, for example:
>>>>>
>>>>> avp_db_delete("$from/username","s:fwd_blind");
>>>>>
>>>>> 3) ALL AVP's for the specified username with an
>>>>> attribute of "fwd_blind" are deleted.
>>>>>
>>>>> If there are multiple entries for the username (some
>>>>> with different domains), they are ALL unexpectedly deleted.
>>>>>
>>>>> A fix would be to change the SQL delete from:
>>>>>
>>>>> DELETE from usr_preferences where username = 'username'
>>>>> and attribute = 'fwd_blind'
>>>>>
>>>>> To:
>>>>>
>>>>> DELETE from usr_preferences where username = 'username'
>>>>> and attribute = 'fwd_blind' and domain = ''
>>>>>
>>>>>
>>>>> I spent a little time looking at way the SQL query is
>>>>> dynamically created and realized that this fix would be
>>>>> able to be done faster ( and with less side effects) by
>>>>> the developer.
>>>>>
>>>>> Regards,
>>>>> Norm
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> You can respond by visiting: 
>>>>> https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1372451&group_id=139143 
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel at openser.org
>>>>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Devel mailing list
>>>> Devel at openser.org
>>>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Devel mailing list
>>> Devel at openser.org
>>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>>
>>>
>>
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>
>
>
>