The patch is so small (just a one-liner) that you should be able to 
apply this change manually in imp/lib/api.php.

John & Jan,

I am willing to test and give feedback, but I don't know how to apply 
the patch. Perhaps you could point me to suitable instructions. I had 
been waiting on someone who *does* know to provide feedback.

Regards,
Peter

Hi Jan,  I posted your info on this bug to the SME Server bug tracker, 
http://bugs.contribs.org/show_bug.cgi?id=4772, and it doesn't look 
like anyone has done any further testing/verification.

I did get something sent to me personally, and had asked that person 
to post to your bugtracker, but that didn't get done either.  Below is 
if the info I received.

"I followed the wiki instructions on horde and funabol sync.  I now have
things working in my test environment.   There are still many things I need
to sort out, some Outlook data fields don't copy to Horde and vice versa,
but the main calendar,notes, tasks, contacts all copy back and forth.  Note,
the check box Enable encryption under funambol security, doesn't work, even
though it doesn't stop the sync.."

I have no other information on the above.  I'll post another update on 
the SME Server bug tracker and tell folks if they don't want to test 
and provide feedback while a developer is looking at this section of 
the code, then don't complain if this feature doesn't work or takes a 
further backseat to other issues.

Thanks,

John H. Bennett IIII

Anyone?

Those still running the stable code, can you please try this patch:
http://cvs.horde.org/diff.php/imp/lib/api.php?rt=horde&r1=1.94.10.21&r2=1.94.10.22&ty=u

I'm also having problems, also on an older version (4.3.4) but I don't 
use dovecot as far as I know.   I use SME 7.4, Funambol, Outlook 2003 
and webmail.  I resort to sql hacks to repair the mess created by 
duplicated records every so often.  I have also adjusted permissions 
to get access to the other realm records from within webmail.

When I synch from Outlook,  The realm issue occurs, first and last 
name are  swapped (every second synch) and the full synch (recover) 
inserts records differently to the standard synch.

At this point this function is not fit for purpose, a pity really.  I 
will see what happens when I get hold of IMP 5.

Paul

I have already rewritten the authentication code in IMP 5, so this 
should not be an issue there.  I don't really have the time/effort to 
pore through this older, code anymore, especially since I already did 
it once and couldn't find the problem.  Someone with this kind of 
setup will have to debug.

I can confirm that this is still an issue for RPC based syncing via 
ICS files from thunderbird. We use "realm" for our imp authentication 
against dovecot. When logging in using "username" , all calendar 
entries created using the horde web interface are owned by 
"username@domain.ca", if we connect lightning using remote calendar 
ICS feed, any calendar items created from lightning are owned by 
"username".



Workarounds so far are:

1. create permissions on the calendar to allow "username" to manage 
the calendar were "username@domain.ca" is the actual owner



2. Configure Dovecot to allow authentication using 
"username@domain.com" by stripping the domain portion, and using this 
full email address as the authentication credentials for the lightning 
prompt.



This should be fixed to be seamless for web and client based connections.



Out horde environment is:

Address Book Address Book (turba) H3 (2.3.2)

Calendar Calendar (kronolith) H3 (2.3.2)

Dynamic Mail Dynamic Mail (dimp) H3 (1.1.3) .

File Manager File Manager (gollem) H3 (1.1)

Filters Filters (ingo) H3 (1.2.2)

Horde Horde (horde) 3.3.5

Mail Mail (imp) H3 (4.3.5)

Mobile Mail Mobile Mail (mimp) H3 (1.1.2)

Notes Notes (mnemo) H3 (2.2.2)

Password Password (passwd) H3 (3.1.1)

Tasks Tasks (nag) H3 (2.3.3)

Tickets Tickets (whups) H3 (1.0)

Time Tracking Time Tracking (hermes) H3 (1.0)

Uh, not how.  we will be a release behind with the updates that were 
released on September 14th.



<?php define('HORDE_VERSION', '3.3.4') ?>

<?php define('IMP_VERSION', 'H3 (4.3.4)') ?>

<?php define('NAG_VERSION', 'H3 (2.3.2)') ?>

<?php define('MNEMO_VERSION', 'H3 (2.2.1)') ?>

<?php define('KRONOLITH_VERSION', 'H3 (2.3.1)') ?>

<?php define('TURBA_VERSION', 'H3 (2.3.1)') ?>

<?php define('INGO_VERSION', 'H3 (1.2.1)') ?>



The horde CHANGES state this this bug was fixed in Horde 3.3 which is 
why I asked the question.  Someone else had stated that it didn't fix 
it for them as well.  I can direct others to this bug to give you the 
necessary information you need.  I just want to make sure you are OK 
with re-opening this one or if you prefer opening a new one.

And *do* you run the latest Horde/IMP versions?

So is this bug really fixed or does this need to be re-opened?  I ask 
based on the above comment.  I run horde on SME Server (based on 
CentOS) and people are still reporting that they can't sync when using 
realms.  I can re-direct those people to this bug if you want, but 
since it's in a closed state, I didn't want to do that before asking.

The other issue 6746 got closed as duplicate and I just upgraded to 
Webmail 1.2 which was supposed to fix my realm/rpc issue but it 
doesn't. I still get a 404 when trying to access my calendar.

This is the expected behavior, the timestamp is only set under certain 
circumstances. I don't understand why at the moment, but that's how 
the code works, intentionally.
Kind of, but there is another ticket about that already (or some 
discussion on the mailing list?).

Now they get set, but the syncml_timestamp is "0" in horde_syncml_map 
for any entry.



When I try delete the SyncmlTimestamps via "Options -> Timestamps of 
successful synchronization sessions -> Delete | Delete all SnyMLData" 
then only the entries in the horde_syncml_anchors table get deleted 
but the horde_syncml_map table remains unchanged.



Is this intended?

(Anyway, I guess it is not related to the realm problem)

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/framework/SyncML/SyncML.php?r1=1.21.10.16&r2=1.21.10.17&ty=u
http://cvs.horde.org/diff.php/framework/SyncML/SyncML/Backend/Horde.php?r1=1.8.2.12&r2=1.8.2.13&ty=u
http://cvs.horde.org/diff.php/framework/SyncML/SyncML/Backend/Sql.php?r1=1.6.2.4&r2=1.6.2.5&ty=u

Yes, it sets to the user that has been sent by the client. Please try 
what I committed.

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/framework/SyncML/SyncML.php?r1=1.75&r2=1.76&ty=u
http://cvs.horde.org/diff.php/framework/SyncML/SyncML/Backend/Horde.php?r1=1.23&r2=1.24&ty=u
http://cvs.horde.org/diff.php/framework/SyncML/SyncML/Backend/Sql.php?r1=1.10&r2=1.11&ty=u

I just noticed that the Timestamps of successful synchronization 
sessions are not being written correctly (realm is missing) to the 
database.

Could be because setUser($user) from SyncML/Backend/Horde.php 78 sets 
the user to the user without realm?



When I set $user = Auth::getAuth(); in this function, then the 
timestamps appear in "Global Options -> SyncML".

Can someone confirm this?

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/framework/Auth/Auth/application.php?r1=1.27.10.15&r2=1.27.10.16&ty=u
http://cvs.horde.org/diff.php/horde/docs/CHANGES?r1=1.515.2.471&r2=1.515.2.472&ty=u

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/horde/docs/CHANGES?r1=1.1164&r2=1.1165&ty=u

This seems to do it, although I didn't test it thoroughly it seems to 
work for both: webdav and syncml

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/framework/Auth/Auth/application.php?r1=1.45&r2=1.46&ty=u

You are correct.  I was not aware of the previous report (which 
probably means I really shouldn't be mucking around with this code in 
the first place).

...hmmm in ticket #6746 Jan told me that this is exactly the same 
issue, therefore I thought your fixes would also apply for the webdav 
stuff, or am I wrong?

AFAICT, this ticket is concerned solely with syncml authentication and 
realm issues.  My fixes correctly set IMP's uniquser variable with the 
realm information (I think/hope), which was the issue reported here.   
Problems with syncing/authentication in general are not the focus of 
this ticket unless they are directly attributable to IMP 
authentication/realm issues.

unfortunately no...

at least not when syncing using webdav

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/imp/lib/api.php?r1=1.94.10.19&r2=1.94.10.20&ty=u

Does this help?

Changes have been made in CVS for this ticket:

http://cvs.horde.org/diff.php/imp/lib/api.php?r1=1.132&r2=1.133&ty=u

Any chance of this being fixed today? I would like to roll the 
releases tomorrow.

Let's try and get this fixed for IMP 4.3.

Both my pre and post patch syncml log files look like this:



DEBUG:  Backend of class syncml_backend_horde created

DEBUG:  Started at 2008-08-29 08:52:22. Packet logged in 
/tmp/sync/client_14.xml

DEBUG:  New session created: 5038b45d6ffc1337852886d81747daa5

DEBUG:  Checking authentication for user tyuhas

DEBUG:  Invalid authentication

DEBUG:  Authenticated: no; version: 1.1; message ID: 1; source URI: 
fmz-bRynSkjE

100plqxQHERhMg==; target URI: 
https://email.arl.arizona.edu:8088/rpc.php; user:

; charset: UTF-8; wbxml: no

DEBUG:  Received <Final> from client.

DEBUG:  Sending <Final> to client

DEBUG:  Return message completed

DEBUG:  Finished at 2008-08-29 08:53:32. Packet logged in 
/tmp/sync/server_14.xm

l



With that username, I can successfully login to Horde (using IMP 
authentication).



Like the other individual, I'm using the Funambol plugin for 
Thunderbird to sync my contact list.  In my earlier tests but with the 
Horde authentication being SMB, I was able to sync with the 
Funambol/Thunderbird combo.

Can anybody experiencing this issue please answer that question?

I just stumbled on this bug from reading the mailing list.  I seem to 
be affected as well.  From the best I can tell, syncing to rpc.php is 
not appending the realm.



I can sync using funambol as the username "path".  It does not see 
anything and uploads my Outlook contacts and so forth.  If I try to 
sync using "path@dtcc.edu", I am not able to authenticate.



Running "SELECT count(*) from horde.horde_prefs WHERE pref_uid='path'" 
on the database shows that ten records are created in that table after 
a sync operation (I ensured that there were not any records for that 
user prior to the sync).  All of my horde data is linked to 
'path@dtcc.edu'.



I tried the patch attached to this ticket and it had no effect (good or bad).



I'm using the stock "Horde Groupware Webmail Edition 1.1.1".  Using 
imp authentication to the imap server.

Sorry, and what was happening (in the logs if you have it) before the patch?



Also, am I understanding correctly that username works for auth, but 
doesn't match up with any data? (with and/or without the patch?) So 
the issue would seem to be that when doing auth via the API, the realm 
isn't added?

username@realm.....I tried it both ways but pasted the wrong portion 
of the log.  Here's the username@realm test with the patch:



DEBUG:  Backend of class syncml_backend_horde created

DEBUG:  Started at 2008-07-01 13:34:21. Packet logged in 
/tmp/sync/client_11.xml

DEBUG:  New session created: 3609e9f199601d790a8bddeebbcc55af

DEBUG:  Checking authentication for user tyuhas@email.arizona.edu

DEBUG:  Invalid authentication

DEBUG:  Authenticated: no; version: 1.1; message ID: 1; source URI: 
fmz-bRynSkjE

100plqxQHERhMg==; target URI: 
https://email.arl.arizona.edu:8088/rpc.php; user:

; charset: UTF-8; wbxml: no

DEBUG:  Received <Final> from client.

DEBUG:  Sending <Final> to client

DEBUG:  Return message completed

DEBUG:  Finished at 2008-07-01 13:34:51. Packet logged in 
/tmp/sync/server_11.xm

l

And is that what you received before? Sending username or username@realm?

In the log, I'm receiving "Invalid authentication"



DEBUG:  Backend of class syncml_backend_horde created

DEBUG:  Started at 2008-07-01 13:36:06. Packet logged in 
/tmp/sync/client_12.xml

DEBUG:  New session created: 6af242c0d8eb164047652ba19ba257e0

DEBUG:  Checking authentication for user tyuhas

DEBUG:  Invalid authentication

DEBUG:  Authenticated: no; version: 1.1; message ID: 1; source URI: 
fmz-bRynSkjE

100plqxQHERhMg==; target URI: 
https://email.arl.arizona.edu:8088/rpc.php; user:

; charset: UTF-8; wbxml: no

DEBUG:  Received <Final> from client.

DEBUG:  Sending <Final> to client

DEBUG:  Return message completed

DEBUG:  Finished at 2008-07-01 13:37:01. Packet logged in 
/tmp/sync/server_12.xm

l

Ping?

By chance, does this patch help?

This is not really related to synching. The code that triggers this 
behavior looks basically like:



$auth = &Auth::singleton($GLOBALS['conf']['auth']['driver']);

$auth->authenticate($username, array('password' => $pwd));



If you use IMP authentication and configured IMP to use realms for the 
preferred server, the realms are not attached. This has something to 
do with the order in which the IMP session is being setup, servers.php 
is loaded, and the different authenticate() and _authenticate() 
methods in Auth::, Auth_application::, and Auth_imp:: are being 
called. This is where I got lost.

Not really sure what I am looking for since I have no experience with 
realms and or syncing.

I'm getting lost in the fragile authentication chain inside IMP. 
Michael, can you see anything?

This rather seems to be a problem with authenticating through the Auth API.

We have an issue similar to ticket #6746 but we're using SyncML via 
the funambol plug-in for contacts syncing w/Lightning.  The sync works 
with our dev horde setup which uses LDAP authentication.  Our main 
site uses IMP authentication and realms which is where the sync is not 
working.



Both Horde installations are Webmail Edition 1.1-RC4.



The user is stored as username@realm but the IMP backend is only 
expecting username.  If we configure the plug-in to send username, it 
fails because username doesn't exist in horde.  If we put 
username@realm, the backend auth fails.