[horde] Horde_History has boolean auth() -> Re: in horde_histories history_who = 'f'

[Steffen]

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