Tue, 21 May 2013 20:03:28 +0000 http://bugs.horde.org/ticket/10617 INGO Auth Generation Incorrect When trying to setup Ingo with my Dovecot Managesieve server I ran into an authentication issue. Ingo was always including the Horde user credential when generating the base64 encoded plain authentication as the first field. I need this field to be blank in order for Dovecot to properly authenticate. I tracked the issue down to a line in ingo/lib/Transport/Timsievd.php. I went ahead an updated the file so it will use the "euser" parameter passed from backends.php or default to using the pre-existing call to Ingo::getUser(false). I have attached a patch detailing the updates I made. Fri, 07 Oct 2011 23:17:31 +0000 http://bugs.horde.org/ticket/10617#t68010 > When trying to setup Ingo with my Dovecot Managesieve server I ran > into an authentication issue. Ingo was always including the Horde > user credential when generating the base64 encoded plain > authentication as the first field. I need this field to be blank in > order for Dovecot to properly authenticate. I don't follow. What are you talking about? > I tracked the issue down to a line in > ingo/lib/Transport/Timsievd.php. I went ahead an updated the file so > it will use the "euser" parameter passed from backends.php or default > to using the pre-existing call to Ingo::getUser(false). I have > attached a patch detailing the updates I made. That doesn't make sense, how is managesieve supposed to know for which user to accept the uploaded script, if you hardcode the effective user to a fixed value? Mon, 10 Oct 2011 16:54:56 +0000 http://bugs.horde.org/ticket/10617#t68065 >> When trying to setup Ingo with my Dovecot Managesieve server I ran >> into an authentication issue. Ingo was always including the Horde >> user credential when generating the base64 encoded plain >> authentication as the first field. I need this field to be blank in >> order for Dovecot to properly authenticate. > > I don't follow. What are you talking about? I am referring to the credential's that are passed to the Net_Sieve object. Specficially always using the horde username as the effective user. > That doesn't make sense, how is managesieve supposed to know for > which user to accept the uploaded script, if you hardcode the > effective user to a fixed value? From what I have been able to gather, the username that is used to authenticate is used as the effective user by Dovecot's managesieve server. When authenticating against Dovecot's managesieve implementation the effective user needs to be set to null. I have attached the perl script Dovecot provides for testing authentication. I agree that setting the effective user to a static string or null does not make sense. The intent of the patch I attached to the ticket was to allow the effective user to be set via backends.local.php in edge cases and keeping the current behavior as the default. Mon, 10 Oct 2011 17:44:54 +0000 http://bugs.horde.org/ticket/10617#t68073 >> That doesn't make sense, how is managesieve supposed to know for >> which user to accept the uploaded script, if you hardcode the >> effective user to a fixed value? > From what I have been able to gather, the username that is used to > authenticate is used as the effective user by Dovecot's managesieve > server. When authenticating against Dovecot's managesieve > implementation the effective user needs to be set to null. I have > attached the perl script Dovecot provides for testing authentication. That's a bug in Dovecot then. The effective user is not (necessarily) the same like the authenticating users, that's why are two different user types. Sun, 13 Nov 2011 20:52:50 +0000 http://bugs.horde.org/ticket/10617#t68786 > That's a bug in Dovecot then. The effective user is not (necessarily) > the same like the authenticating users, that's why are two different > user types. I completely agree. I was not asking the default behavior of INGO to be changed. I was hoping that it could be updated to allow the default behavior to be overridden in the configuration for edge cases like I ran into. The diff that I attached to the ticket maintains the default INGO behavior while allowing administrators to specify a different value if they so choose. Tue, 15 Nov 2011 16:09:49 +0000 http://bugs.horde.org/ticket/10617#t68878 Here is the hook for Horde 5 that needs to be added in horde/ingo/config public function transport_auth($driver) { switch ($driver) { case 'timsieved': return array( 'username' => $GLOBALS['registry']->getAuth(null), 'euser' => $GLOBALS['registry']->getAuth(null) ); } // DEFAULT: Use hordeauth (identical to not defining hook at all). return true; } Tue, 06 Nov 2012 17:25:31 +0000 http://bugs.horde.org/ticket/10617#t74498 Yes, this was resolved with addition of the hook in Ingo 3. Tue, 06 Nov 2012 18:59:17 +0000 http://bugs.horde.org/ticket/10617#t74512