Fri, 10 Apr 2026 06:14:15 +0000 https://bugs.horde.org/ticket/6903 Silence warning on creation/update of a Kolab object Hello Gunnar, attached patch silences a stupid warning on creation/update of a Kolab object. The warning looks like this: [Thu Jun 12 11:06:32 2008] [error] [client 172.16.1.2] PHP Notice: Unknown: Missing or invalid host name after @ (errflg=3) in Unknown on line 0, referer: http://intratest3.m.i2n/horde/turba/contact.php?source=friedrich&key=200806121 ... Thomas Thu, 12 Jun 2008 09:13:17 +0000 https://bugs.horde.org/ticket/6903#t46307 This looks not okay to me. Auth::getAuth() will usually resolve to something like wrobel@example.org. Your patch would lead to "wrobel@example.org@example.org" or am I missing something? You are having that problem on the special users (like admins, maintainers etc.)? Or on standard users? For a standard Kolab user Auth::getAuth() should ALWAYS return a valid mail address. Otherwise the inital UID rewrite failed. Fri, 13 Jun 2008 08:33:04 +0000 https://bugs.horde.org/ticket/6903#t46381 > This looks not okay to me. > > Auth::getAuth() will usually resolve to something like wrobel@example.org. Oh, Auth::getAuth() always returns just the username for me. If it returns a complete email address, then my patch needs some tweaking. It happens for all users IIRC. Auth::getAuth() is defined as "user id". I'm not sure if it always must contain an @domain part. Fri, 13 Jun 2008 08:39:57 +0000 https://bugs.horde.org/ticket/6903#t46385 Ups, somehow missed your response to this one. Sorry for the late reply... >> This looks not okay to me. >> >> Auth::getAuth() will usually resolve to something like wrobel@example.org. > > Oh, Auth::getAuth() always returns just the username for me. If it > returns a complete email address, then my patch needs some tweaking. > It happens for all users IIRC. > > Auth::getAuth() is defined as "user id". I'm not sure if it always > must contain an @domain part. > Are you using the Auth::kolab driver then? The kolab driver should rewrite the user id to the primary mail adress (see the setAuth() function in that driver). It looks like you are using UIDs in your system. At least in former times that was problematic for other Horde subsystems and that is why the kolab driver does the rewrite. I admit I don't remember exactly what the effects of using a UID were. But my gut feeling is that even with our new infrastructure it makes more sense to use the primary Kolab ID. Wed, 25 Jun 2008 07:20:14 +0000 https://bugs.horde.org/ticket/6903#t46791 >> Auth::getAuth() is defined as "user id". I'm not sure if it always >> must contain an @domain part. > > Are you using the Auth::kolab driver then? The kolab driver should > rewrite the user id to the primary mail adress (see the setAuth() > function in that driver). It looks like you are using UIDs in your > system. At least in former times that was problematic for other Horde > subsystems and that is why the kolab driver does the rewrite. I admit > I don't remember exactly what the effects of using a UID were. But my > gut feeling is that even with our new infrastructure it makes more > sense to use the primary Kolab ID. I'm using IMP as Auth backend, which authenticates against an IMAP server. Everything works fine, no complaints from the users so far. If some part of the Kolab subsystem does work only with the Kolab Auth backend, then it needs fixing :-) I'll have an idea that satisfies both your needs: Why not check the From: and To: address for the "@" character and append "@localhost" only if it is not found? Thomas Tue, 01 Jul 2008 07:19:06 +0000 https://bugs.horde.org/ticket/6903#t47066 Changes have been made in CVS for this ticket: http://cvs.horde.org/diff.php/framework/Kolab/Kolab/Storage/Folder.php?r1=1.7&r2=1.8&ty=u http://cvs.horde.org/diff.php/framework/Kolab/Kolab/Storage/Session.php?r1=1.1&r2=1.2&ty=u http://cvs.horde.org/diff.php/framework/Kolab/tests/Horde/Kolab/Storage/DataTest.php?r1=1.2&r2=1.3&ty=u http://cvs.horde.org/diff.php/framework/Kolab/tests/Horde/Kolab/Storage/ListTest.php?r1=1.2&r2=1.3&ty=u http://cvs.horde.org/diff.php/framework/Kolab/tests/Horde/Kolab/Storage/SessionTest.php?r1=1.2&r2=1.3&ty=u Wed, 02 Jul 2008 07:36:35 +0000 https://bugs.horde.org/ticket/6903#t47093 >>> Auth::getAuth() is defined as "user id". I'm not sure if it always >>> must contain an @domain part. >> >> Are you using the Auth::kolab driver then? The kolab driver should >> rewrite the user id to the primary mail adress (see the setAuth() >> function in that driver). It looks like you are using UIDs in your >> system. At least in former times that was problematic for other Horde >> subsystems and that is why the kolab driver does the rewrite. I admit >> I don't remember exactly what the effects of using a UID were. But my >> gut feeling is that even with our new infrastructure it makes more >> sense to use the primary Kolab ID. > > I'm using IMP as Auth backend, which authenticates against an IMAP server. Ah, now I understand. > > Everything works fine, no complaints from the users so far. If some > part of the Kolab subsystem does work only with the Kolab Auth > backend, > then it needs fixing :-) Yes, true. > > I'll have an idea that satisfies both your needs: Why not check the > From: and To: address for the "@" character and append "@localhost" > only if it is not found? As this is just the mail address in the object I guess it could be done that way. But it feels little bit too much like a hack to me. Especially since we should have the possibility to retrieve the users primary mail address from LDAP on any reasonable Kolab server. This is what I implemented in the new framework now. The Session handler was fetching the Kolab user object anyhow, so retrieving and storing the primary mail was just a small addon. I added your solution in the session handler as a last backup in case querying the LDAP server didn't help. The session handler caches the primary mail address so it should not slow down the writing of Kolab messages to IMAP by first querying LDAP. > > Thomas > Wed, 02 Jul 2008 07:41:03 +0000 https://bugs.horde.org/ticket/6903#t47094 Please reopen in case the current approach does not work for you. Wed, 02 Jul 2008 07:41:45 +0000 https://bugs.horde.org/ticket/6903#t47095 > Please reopen in case the current approach does not work for you. The code change look good to me, thanks. I'll check it next week in detail. Wed, 02 Jul 2008 07:45:07 +0000 https://bugs.horde.org/ticket/6903#t47096