[horde] Horde_History has boolean auth() -> Re: in horde_histories history_who = 'f'
Steffen
skhorde at smail.inf.fh-bonn-rhein-sieg.de
Tue Mar 25 15:07:54 UTC 2014
On Thu, 20 Mar 2014, Jan Schneider wrote:
> Zitat von "Jens-U. Mozdzen" <jmozdzen at nde.ag>:
>
>> Hi Steffen,
>>
>> Zitat von Steffen <skhorde at smail.inf.fh-bonn-rhein-sieg.de>:
>>> if an user adds/deletes/... events via CalDAV or ActiveSync or Mnemos or
>>> Tasks via "Task & notes" for Android, horde_histories gets an entry where
>>> history_who is 'f'. I do not have no user 'f' and the users in question do
>>> not configured this user 'f', but their own.
>>>
>>> I've created a backtrace for one issue, when prefs_init() called user data
>>> for the non-existing user 'f'. Here _buildNote() called getUserName(),
>>> which queried horde_histories, which returned 'f'. The note is located in
>>> my notepad and I've setup the app to use my account.
>>>
>>> If I add a new note with "Task& notes" for Android, I get a new entry in
>>> horde_histories with history_who = 'f'. The same applies, if I add a new
>>> event with CalDAV clients in KDE and Android.
>>>
>>> Shouldn't history_who contain the username used to make the changes?
>>> Besides the fact, that there might exist the user "f".
>>> Or might there a configuration mistake?
>
> Cannot reproduce, my history table looks fine.
>
>> I just checked our according table - while most of the entries do have the
>> user's email address in the history_who field, some do have "0". These
>> entries seem to be spread access all applications - object_uid does start
>> with "imp:", "turba:", "nag:", "kronolith:" and so on. "history_action" is
>> "add, "modify", "delete" - so again spread.
>
> I see this on exactly 6 records, which I can lightheartedly justify with some
> development reminiscence.
>
>> The first occurrence of such an extraordinary entry was at time stamp
>> "1357325373" (Jan 4, 2013), mod_seq 382 - almost one year after the first
>> history entry (Feb 2012) on this installation. The latest occurrence is
>> from yesterday, so it happens with current code, too.
In Horde/History.php
// here $attributes contains only "action"
if (!isset($attributes['who'])) {
$attributes['who'] = $this->_auth;
}
// $this->_auth is "false", I mean:
if(!is_string($attributes['who'])) {
my_dump("Log User \$attr=".var_export($attributes, true)."\n");
// overwrite boolean value
$attributes['who'] = $GLOBALS['registry']->getAuth();
}
produces:
Log User $attr=array (
'action' => 'add',
'who' => false,
)
So in my case with Postgres who == false is mapped to 'f', I suppose,
whereas in other databases it is mapped to '0'.
Although I overwrite the "false" value with getAuth() and I do not have
entries with 'f' in horde_histories, I do see queries for user "f" in
prefs_init() hook. So, the 'f' entries in the database are not the cause,
but a symptom for another bug.
--
Steffen
More information about the horde
mailing list