Summary | ical webdav and realms |
Queue | Kronolith |
Queue Version | HEAD |
Type | Bug |
State | Duplicate |
Priority | 2. Medium |
Owners | slusarz (at) horde (dot) org |
Requester | adrieder (at) sbox (dot) tugraz (dot) at |
Created | 05/23/2008 (6229 days ago) |
Due | |
Updated | 09/25/2008 (6104 days ago) |
Assigned | 05/25/2008 (6227 days ago) |
Resolved | 09/25/2008 (6104 days ago) |
Github Issue Link | |
Github Pull Request | |
Milestone | |
Patch | No |
Assigned to Michael Slusarz
Taken from
State ⇒ Duplicate
Ticket #6749.a separate ticket for it?
is set to this combination?
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.
is set to this combination?
imp but it works.
What about doing it in a conditional way? I mean just if the driver is
set to this combination?
imp but it works.
subsequent checks (inside the various api methods) should return
empty for Auth::getAuth().
:-) 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.
subsequent checks (inside the various api methods) should return empty
for Auth::getAuth().
the authenticate method with the "login = false" parameter:
$auth->authenticate($username, array('password' => $password), false);
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
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.
doesn't have anything to do with SyncML.
Assigned to
Version ⇒ HEAD
Queue ⇒ Kronolith
doesn't have anything to do with SyncML.
Priority ⇒ 1. Low
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Due ⇒ 05/23/2008
Summary ⇒ ical webdav and realms
Type ⇒ Bug
Queue ⇒ Synchronization
servers.php then it is not possible to fetch calendars via webdav. See
also: <http://marc.info/?l=horde-dev&m=121136921813785&w=2>