6.0.0-beta1
7/8/25

[#10617] INGO Auth Generation Incorrect
Summary INGO Auth Generation Incorrect
Queue Ingo
Queue Version 3.0.0
Type Bug
State Resolved
Priority 2. Medium
Owners slusarz (at) horde (dot) org
Requester mcrosson_horde (at) nusku (dot) net
Created 10/07/2011 (5023 days ago)
Due
Updated 11/06/2012 (4627 days ago)
Assigned 10/10/2011 (5020 days ago)
Resolved 11/06/2012 (4627 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch Yes

History
11/06/2012 06:59:17 PM Michael Slusarz Comment #7
Assigned to Michael Slusarz
State ⇒ Resolved
Version ⇒ 3.0.0
Reply to this comment
Yes, this was resolved with addition of the hook in Ingo 3.
11/06/2012 05:25:31 PM software-horde (at) interfasys (dot) ch Comment #6 Reply to this comment
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;
     }


11/15/2011 04:09:49 PM mcrosson_horde (at) nusku (dot) net Comment #5 Reply to this comment
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.
11/13/2011 08:52:50 PM Jan Schneider Comment #4 Reply to this comment
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.
10/10/2011 05:44:54 PM mcrosson_horde (at) nusku (dot) net Comment #3
New Attachment: sieve-auth-command.pl Download
Reply to this comment
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.
10/10/2011 04:54:56 PM Jan Schneider Comment #2
Priority ⇒ 2. Medium
State ⇒ Feedback
Reply to this comment
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?
10/07/2011 11:17:31 PM mcrosson_horde (at) nusku (dot) net Comment #1
Priority ⇒ 3. High
Type ⇒ Bug
Summary ⇒ INGO Auth Generation Incorrect
Queue ⇒ Ingo
Milestone ⇒
Patch ⇒ Yes
New Attachment: Timsieved.php.diff Download
State ⇒ Unconfirmed
Reply to this comment
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.

Saved Queries