6.0.0-alpha12
6/12/25

[#6746] ical webdav and realms
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

History
09/25/2008 03:19:03 AM Michael Slusarz Comment #16
Assigned to Michael Slusarz
Taken from Horde DevelopersHorde Developers
State ⇒ Duplicate
Reply to this comment
Marking as duplicate of Ticket #6749.
09/19/2008 08:27:02 AM Jan Schneider Priority ⇒ 2. Medium
 
08/28/2008 07:53:37 AM adrieder (at) sbox (dot) tugraz (dot) at Comment #15 Reply to this comment
Ping
06/16/2008 05:51:33 PM Jan Schneider Comment #14 Reply to this comment
No, it's exactly the same issue.
06/16/2008 09:54:40 AM adrieder (at) sbox (dot) tugraz (dot) at Comment #13 Reply to this comment
I see that also syncml is affected by the same problem. Should I open 
a separate ticket for it?
06/10/2008 09:30:58 PM adrieder (at) sbox (dot) tugraz (dot) at Comment #12 Reply to this comment
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.




06/10/2008 08:34:39 PM Chuck Hagenbuch Comment #11 Reply to this comment
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.
06/10/2008 08:33:24 PM adrieder (at) sbox (dot) tugraz (dot) at Comment #10 Reply to this comment
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?
06/10/2008 08:11:24 PM Chuck Hagenbuch Comment #9 Reply to this comment
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.
06/10/2008 08:09:53 PM adrieder (at) sbox (dot) tugraz (dot) at Comment #8 Reply to this comment
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.


06/10/2008 06:34:01 PM Chuck Hagenbuch Comment #7 Reply to this comment
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().
06/10/2008 01:57:19 PM adrieder (at) sbox (dot) tugraz (dot) at Comment #6 Reply to this comment
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.
06/06/2008 01:07:02 PM adrieder (at) sbox (dot) tugraz (dot) at Comment #5 Reply to this comment
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
06/05/2008 09:55:35 AM adrieder (at) sbox (dot) tugraz (dot) at Comment #4 Reply to this comment
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.
05/26/2008 01:20:56 PM adrieder (at) sbox (dot) tugraz (dot) at Comment #3 Reply to this comment
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


05/25/2008 02:25:57 PM Jan Schneider State ⇒ Assigned
Assigned to Horde DevelopersHorde Developers
 
05/25/2008 02:25:34 PM Jan Schneider Comment #2
Version ⇒ HEAD
Queue ⇒ Kronolith
Reply to this comment
Not sure if this is an IMP or Kronolith problem, but it definitely 
doesn't have anything to do with SyncML.
05/23/2008 02:45:27 PM adrieder (at) sbox (dot) tugraz (dot) at Comment #1
Priority ⇒ 1. Low
State ⇒ Unconfirmed
Patch ⇒ No
Milestone ⇒
Due ⇒ 05/23/2008
Summary ⇒ ical webdav and realms
Type ⇒ Bug
Queue ⇒ Synchronization
Reply to this comment
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>

Saved Queries