[kronolith] Event notification from another user private calendar

[Jan Schneider]

Zitat von Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Jan Schneider <jan at horde.org>:
>>
>>> Zitat von Jens Wahnes <wahnes at uni-koeln.de>:
>>>
>>>> Michael J Rubinsky wrote:
>>>>
>>>>> Quoting Jens Wahnes <wahnes at uni-koeln.de>:
>>>>>
>>>>>> On Tue, Feb 16 2016, at 11:49:41 -0200, Luis Felipe Marzagao wrote:
>>>>>>
>>>>>>> Em 15/02/2016 11:47, Luis Felipe Marzagao escreveu:
>>>>>>>> Hello:
>>>>>>>>
>>>>>>>> I´ve just been notified in kronolith (the orange bottom-right box)
>>>>>>>> about
>>>>>>>> an event that was created by another user in his private calendar.
>>>>>>>>
>>>>>>>> I do not have access to that calendar. It´s not listed in my shared
>>>>>>>> calendars.
>>>>>>>>
>>>>>>>> If I click on the event name at the orange notification box I get a
>>>>>>>> "Event not found" error (red box). Probably because I don´t  
>>>>>>>> have access
>>>>>>>> to that event, as expected, since it´s private for that user.
>>>>>>>>
>>>>>>>> We are using kronolith 4.2.14.
>>>>>>>
>>>>>>> Today it has happened again.
>>>>>>
>>>>>> I didn't notice this on our test server, but since we updated our main
>>>>>> server to the latest versions of Horde (including Kronolith 4.2.15),
>>>>>> this is happening to us as well.
>>>>>>
>>>>>> The problem seems to stem from the horde-alarms script being run (a
>>>>>> cronjob in our case). After the update, the horde-alarms script
>>>>>> consumes way more memory than before and takes ages to run (before:
>>>>>> less than a second, after the upgrade: more than a minute).
>>>>>
>>>>> There was a bug in the code that polls each application for alarms. We
>>>>> weren't actually polling the applications at all in certain cases. This
>>>>> commit:
>>>>>
>>>>> https://github.com/horde/horde/commit/4b482074340bf4e7ddc469d69172c5c0a2c761f8
>>>>>
>>>>>
>>>>> fixed the issue, and probably explains the longer execution time, since
>>>>> each application is now actually polled. I'm not seeing your other
>>>>> issue, but will look into it further.
>>>>
>>>> I did some testing with higher debug levels during a run of the  
>>>> horde-alarms script which generated a ton of output which I've  
>>>> been wading through.  One thing that caught my attention was a  
>>>> query that was logged and looks like this:
>>>>
>>>> SELECT * FROM kronolith_sharesng WHERE share_name = 0 [pid 18524  
>>>> on line 321 of "/usr/share/pear/Horde/Db/Adapter/Mysqli.php"]
>>>
>>> We don't have any code that creates this query, I wonder where  
>>> it's coming from.
>>
>> Actually we do, but in the SQL driver, while the query contains a  
>> table name from SQLNG driver. This sounds like some mess-up.
>
> Horde_Share_Sqlng extends Horde_Share_Sql. I don't see anything  
> wrong with that query being executed for a Sqlng backend. It's the  
> fact that the share name is '0' when Horde_Share_Base::getShare() is  
> called that is questionable.

Ah, right, I missed that the one extends the other.

>>>> Note that there is a zero as query parameter here. If you run  
>>>> this query, it returns the complete list of all shares (well, at  
>>>> least with MySQL), and if you suppose that the code now picks the  
>>>> first share_owner from that list, this might be the cause why the  
>>>> notifications a wrongfully assigned to the user with the lowest  
>>>> share_id in the kronolith_sharesng table.
>>>>
>>>> This *might* be a happening only when there are "old style"  
>>>> share_names in the table, i.e. share_names that are equal to the  
>>>> user name of the owner of the calendar (equal to alarm_uid or  
>>>> share_owner for that matter) and not some random string as is the  
>>>> case nowadays for share_name.  I tried to fiddle around with this  
>>>> a bit to make certain, but it's hard to test without destroying  
>>>> data in the tables. Maybe it happens only if that user with the  
>>>> lowest share_id in kronolith_shares_ng also has got real entries  
>>>> in kronolith_events as well.  I can't really tell.
>>>>
>>>> From the logfile with the queries generated during a run of the  
>>>> horde-alarms script, I can also tell that the other (later)  
>>>> queries of the type
>>>>
>>>> SELECT * FROM kronolith_sharesng WHERE share_name = ...
>>>>
>>>> look OK, that is they have a user name (equal to the share name)  
>>>> there and not a zero, so this *might* have to do with some  
>>>> variable that is not initialized on the first time a loop is run.  
>>>>  This is of course only speculation, but it's hard for me to  
>>>> pinpoint the exact cause because the debug log file is huge and I  
>>>> don't really know what to look for.
>>>>
>>>>
>>>> Jens
>>>
>>>
>>>
>>> -- 
>>> Jan Schneider
>>> The Horde Project
>>> http://www.horde.org/
>>
>>
>>
>> -- 
>> Jan Schneider
>> The Horde Project
>> http://www.horde.org/
>>
>> -- 
>> kronolith mailing list
>> Frequently Asked Questions: http://wiki.horde.org/FAQ
>> To unsubscribe, mail: kronolith-unsubscribe at lists.horde.org



-- 
Jan Schneider
The Horde Project
http://www.horde.org/