Marking as duplicate of Ticket #6749.

Ping

No, it's exactly the same issue.

I see that also syncml is affected by the same problem. Should I open 
a separate ticket for it?

I understand.

I hope I could at least help tracking the problem. I'm looking forward 
to the fix of the _actual_ bug and will use the quick hack meanwhile.

Then if we fix the _actual_ bug it'll break again. Still no.

:-)

What about doing it in a conditional way? I mean just if the driver is 
set to this combination?

... and breaks webdav for everyone else. nice. Not going to be committed.

if you carefully follow the calls that are made (it took me some time 
:-) you will be faster) when the authdriver is set to application - 
imp then you will see that the imp api authenticate method will call 
IMP_Session::createSession and there 
$auth_imp->authenticate($_SESSION['imp']['uniquser'], array('password' 
=> $password), true) will be called where the "login" parameter is set 
to "true" so the user gets logged in.

But when you set the "login" parameter "true" also in the authenticate 
call from webdav, this instance of Auth will then overwrite the auth 
credentials set by $auth_imp.



ok, the fix might work only with the auth driver set to application + 
imp but it works.

I don't see how that works; without actually logging the user in, 
subsequent checks (inside the various api methods) should return empty 
for Auth::getAuth().

I tested this for a while now and it seems to work fine.

I think I found the problem. But it is complicated for me to explain, 
I'll try anyway and hope that someone can follow my potentially 
confusing words, sorry for that:



When RPC webdav does "check_auth", first a Horde Auth instance of 
Auth_application is created and the Auth::authenticate method stores 
the credentials with the plain $userId (no realm) then the imp api 
method "authenticate" is called by (Auth_application) "_authenticate". 
The imp api method "authenticate" calls createSession from 
imp/lib/Session.php where the realm gets added to the userId.   
$_SESSION['imp']['user'] and $_SESSION['imp']['uniquser'] are stored.

Now a second Auth instance of type Auth_imp is created and 
Auth_imp::authenticate is called which then calls the 
parent::authenticate (Auth::authenticate) again which now stores the 
credentials with the realmed $userId. The Auth_imp::_authenticate 
method then authenticates the user at the imap server and the 
Auth::setAuth sets the realmed userId after that the Auth_imp is done.

Now the first Auth instance goes on with the authenticate method and 
sets the plain userId via Auth::setAuth which over writes the realmed 
userId that was set by the Auth_imp instance.



To avoid this behavior I was thinking of changing webdav.php and call 
ind the authenticate method with the "login = false" parameter:



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



when using imp as authentication driver (the Auth_imp instance set it 
to true anyway by itself).

By doing this the Auth::setAuth from the initial Auth instance is not 
called and therefore it is not overwriting the credentials which where 
set by the Auth_imp instance.



Any comments on that?



Didi

I tried to track the problem. So far I just see that the userId in the 
session gets overwritten by a the userID without @realm sometime after 
the session is created by imp/lib/Session.php

Therefore Auth::getAuth returns the plain userID without the realm and 
no calendars of shares are found for it.

ok, sorry for that

Not sure if this is an IMP or Kronolith problem, but it definitely 
doesn't have anything to do with SyncML.

When using imp as authentication application and realms are set in 
servers.php then it is not possible to fetch calendars via webdav. See 
also: <http://marc.info/?l=horde-dev&m=121136921813785&w=2>