ical webdav and realms

When using imp as authentication application and realms are

Fri, 23 May 2008 14:45:27 +0000

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:

Not sure if this is an IMP or Kronolith problem, but it defi

Sun, 25 May 2008 14:25:34 +0000

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

> Not sure if this is an IMP or Kronolith problem, but it de

Mon, 26 May 2008 13:20:56 +0000

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

I tried to track the problem. So far I just see that the use

Thu, 05 Jun 2008 09:55:35 +0000

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.

I think I found the problem. But it is complicated for me to

Fri, 06 Jun 2008 13:07:02 +0000

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

> To avoid this behavior I was thinking of changing webdav.p

Tue, 10 Jun 2008 13:57:19 +0000

> To avoid this behavior I was thinking of changing webdav.php and call > the authenticate method with the "login = false" parameter: > > $auth->authenticate($username, array('password' => $password), false); I tested this for a while now and it seems to work fine.

I don't see how that works; without actually logging the use

Tue, 10 Jun 2008 18:34:01 +0000

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 don't see how that works; without actually logging the u

Tue, 10 Jun 2008 20:09:53 +0000

> 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(). 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.

> ok, the fix might work only with the auth driver set to ap

Tue, 10 Jun 2008 20:11:24 +0000

> ok, the fix might work only with the auth driver set to application + > imp but it works. ... and breaks webdav for everyone else. nice. Not going to be committed.

>> ok, the fix might work only with the auth driver set to a

Tue, 10 Jun 2008 20:33:24 +0000

>> ok, the fix might work only with the auth driver set to application + >> imp but it works. > > ... and breaks webdav for everyone else. nice. Not going to be committed. :-) What about doing it in a conditional way? I mean just if the driver is set to this combination?

> What about doing it in a conditional way? I mean just if t

Tue, 10 Jun 2008 20:34:39 +0000

> What about doing it in a conditional way? I mean just if the driver > is set to this combination? 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

Tue, 10 Jun 2008 21:30:58 +0000

>> What about doing it in a conditional way? I mean just if the driver >> is set to this combination? > > Then if we fix the _actual_ bug it'll break again. Still no. 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.

I see that also syncml is affected by the same problem. Shou

Mon, 16 Jun 2008 09:54:40 +0000

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

No, it's exactly the same issue.

Mon, 16 Jun 2008 17:51:33 +0000

No, it's exactly the same issue.

Ping

Thu, 28 Aug 2008 07:53:37 +0000

Ping

Marking as duplicate of Ticket #6749.

Thu, 25 Sep 2008 03:19:03 +0000

Marking as duplicate of Ticket #6749.