[kronolith] Event notification from another user private calendar

[Luis Felipe Marzagao]

Em 18/02/2016 18:31, Michael J Rubinsky escreveu:
>
> Quoting 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"]
>
> This is probably coming from Kronolith_Application::listAlarms().
>
> As an admin user, execute the following from the admin phpshell page,
> using kronolith's scope:
>
> var_dump(array_keys($injector->getInstance('Kronolith_Shares')->listAllShares()));
>
>
> You should see an array of share_names. If I'm right, one of these will
> be '0' for some unknown reason.

Yep, for me it does. The 23th item:

array(24) {
   [0]=>
   string(23) "0ZiHPQiFsvBP6PWQoSL0iwA"
   [1]=>
   string(32) "11e3b9f2f49fab07664945d4cede8469"
   [2]=>
   string(32) "57f3b572c7d8276e65b91e3cd346b172"
   [3]=>
   string(32) "5bdc6fa2c97cecef501b34c47c14d9f9"
   [4]=>
   string(2) "ac"
   [5]=>
   string(4) "acfs"
   [6]=>
   string(13) "Administrator"
   [7]=>
   string(3) "aps"
   [8]=>
   string(3) "cel"
   [9]=>
   string(3) "daa"
   [10]=>
   string(2) "em"
   [11]=>
   string(23) "FmzDcAiFsvBP1WO3OgIwOPA"
   [12]=>
   string(23) "f_B_EAlE4RdL8ZGJ9IzxuQ5"
   [13]=>
   string(3) "ibl"
   [14]=>
   string(4) "lfbm"
   [15]=>
   string(3) "mes"
   [16]=>
   string(4) "rabm"
   [17]=>
   string(5) "rabmj"
   [18]=>
   string(4) "robm"
   [19]=>
   string(23) "SZtmkeuHIuoMv74QHovb1A1"
   [20]=>
   string(4) "veri"
   [21]=>
   string(4) "vmlr"
   [22]=>
   string(3) "vsg"
   [23]=>
   int(0)


>
>
>> 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
>
>
>
>
>