Hi roundcube folks--
http://trac.roundcube.net/ticket/1486802 was about roundcube failures to move drafts, sent messages, and deleted messages into their proper folders.
It looks to me like it was fixed for drafts and sent messages, but it was *not* fixed for deleted messages. I can't seem to convince http://trac.roundcube.net/ to let me have an account, but i think that ticket should be re-opened.
I think the attached patch fixes the situation for the trash (as well as fixing any other attempt to move into a folder that doesn't exist).
Arguably, you might also want to subscribe to the newly-created folder, and not just create it; but as a baseline, i think this is a reasonable patch against v0.8.4.
Please let me know if there's anything i should do to help get this adopted, or if there's some reason that this patch itself is a bad idea.
Thanks for roundcube,
--dkg
On 11/16/2012 02:11 AM, Daniel Kahn Gillmor wrote:
http://trac.roundcube.net/ticket/1486802 was about roundcube failures to move drafts, sent messages, and deleted messages into their proper folders.
It looks to me like it was fixed for drafts and sent messages, but it was *not* fixed for deleted messages. I can't seem to convince http://trac.roundcube.net/ to let me have an account, but i think that ticket should be re-opened.
I think the attached patch fixes the situation for the trash (as well as fixing any other attempt to move into a folder that doesn't exist).
Any word on this? Is this patch something worth fixing? If it's the wrong approach, or you think it is a mistake, i'd be happy to hear an explicit rejection (and a suggestion of what to improve would be welcome too).
Thanks very much for roundcube,
--dkg
On 11/16/2012 08:11 AM, Daniel Kahn Gillmor wrote:
It looks to me like it was fixed for drafts and sent messages, but it was *not* fixed for deleted messages. I can't seem to convince http://trac.roundcube.net/ to let me have an account, but i think that ticket should be re-opened.
I think the attached patch fixes the situation for the trash (as well as fixing any other attempt to move into a folder that doesn't exist).
There's a logic in rcube_imap::move_message() which creates a destination folder if it doesn't exist but only for default (special) folders. Doesn't it work for you? According to your patch, now we'd have redundant check for folder existence.
I think we shouldn't do this for non-special folders.
Arguably, you might also want to subscribe to the newly-created folder, and not just create it; but as a baseline, i think this is a reasonable patch against v0.8.4.
It also subscribes to such folder.
On 12/04/2012 02:32 AM, A.L.E.C wrote:
There's a logic in rcube_imap::move_message() which creates a destination folder if it doesn't exist but only for default (special) folders. Doesn't it work for you? According to your patch, now we'd have redundant check for folder existence.
I think we shouldn't do this for non-special folders.
Hm. this is confusing, but i agree with you now, looking at the code. I don't think the changeset i'd offered should have any effect.
And indeed, testing it now i don't see any difference. I reverted the change on my installation, and i'll follow up more if i still run into the problems i was seeing earlier somehow.
Thanks for your reply, alec. sorry for the confusion!
--dkg
Hi all,
I'm new here and with RoundCube deployment, and I'm looking for some advices on how to do improvements or feature for our use of roundcube.
My needs are for the adressbook feature using an LDAP, we would like to do dynamic's filters depending on users attributes obtained at the connection with a LDAP request.
So my question is : What is the best way on how to get attributes needed in user definition ? extends user object ? But How (I'm not an advanced developper in PHP) in this case to be integrated in RoundCube sources ? or adding these attributes in session but it's not very elegant ? Other way ? Is it possible with a hook for example or an with a plugin ? At least i know that i need to modify the plugin new_user_identity with the ldap part or to use an other plugin to get the attributes needed.
Thank you in advance for any help that you could provide.
Thanks, Julien
On 2012-12-05 16:44, Julien Gribonvald wrote:
My needs are for the adressbook feature using an LDAP, we would like to do dynamic's filters depending on users attributes obtained at the connection with a LDAP request.
Are you saying that you need, for example, a filter of:
(&(objectclass=inetorgperson)(location:$branch_office_1))
for somebody that logs in that has an LDAP attribute 'location' set to '$branch_office_1', or something along similar lines?
You may want to consider something along the lines of (OpenLDAP slapd.conf syntax):
access to dn.subtree="ou=people,dc=example,dc=org" by set.exact="this/location & user/location" read by * none
which reads as follows:
Read, search, compare, auth and disclose access is granted to entries in the OU=People sub-tree, for which the 'location' attribute value on the entry searched/found is equal to the 'location' attribute value for the user that bound to LDAP.
This way, there's no need to modify code, and it'll work for other LDAP clients as well.
Kind regards,
Jeroen van Meeuwen
Thanks for your response,
The things is that we doesn't use LDAP auth but the CAS auth. After we doesn't permit user auth and access to ldap so I don't think that we can use your example if I understood your ldap configuration.
Julien
Le 05/12/2012 19:13, Jeroen van Meeuwen (Kolab Systems) a écrit :
On 2012-12-05 16:44, Julien Gribonvald wrote:
My needs are for the adressbook feature using an LDAP, we would like to do dynamic's filters depending on users attributes obtained at the connection with a LDAP request.
Are you saying that you need, for example, a filter of:
(&(objectclass=inetorgperson)(location:$branch_office_1))
for somebody that logs in that has an LDAP attribute 'location' set to '$branch_office_1', or something along similar lines?
You may want to consider something along the lines of (OpenLDAP slapd.conf syntax):
access to dn.subtree="ou=people,dc=example,dc=org" by set.exact="this/location & user/location" read by * none
which reads as follows:
Read, search, compare, auth and disclose access is granted to entries in the OU=People sub-tree, for which the 'location' attribute value on the entry searched/found is equal to the 'location' attribute value for the user that bound to LDAP.
This way, there's no need to modify code, and it'll work for other LDAP clients as well.
Kind regards,
Jeroen van Meeuwen
On 2012-12-05 18:23, Julien Gribonvald wrote:
Thanks for your response,
The things is that we doesn't use LDAP auth but the CAS auth. After we doesn't permit user auth and access to ldap so I don't think that we can use your example if I understood your ldap configuration.
My example wasn't so much related to the user authentication itself as it was to authorization within LDAP.
I was indeed assuming the user was required to bind to LDAP (as themselves / with their own credentials) - I figured it was a reasonable assumption as otherwise all information contained in the LDAP tree is public / commonly available to all, but perhaps it wasn't ;-)
I'd still like to learn if my description of your functional requirement was indeed somewhat correct / accurate:
On 2012-12-05 18:13, Jeroen van Meeuwen (Kolab Systems) wrote:
Are you saying that you need, for example, a filter of:
(&(objectclass=inetorgperson)(location:$branch_office_1))
for somebody that logs in that has an LDAP attribute 'location' set to '$branch_office_1', or something along similar lines?
That said, I reckon Roundcube still logs in to an IMAP server using some sort of set of credentials, correct? Could these credentials not also be used to "log in" (bind) to LDAP?
Please allow me to state a snippet of (stock, off-the-shelf) Roundcube configuration that we use:
/etc/roundcubemail/main.inc.php:
'user_specific' => true, 'base_dn' => 'dc=example,dc=org', 'bind_dn' => '%dn', 'bind_pass' => '', 'search_base_dn' => 'dc=example,dc=org', 'search_bind_dn' => 'uid=some-service-account,ou=Some OU,dc=example,dc=org', 'search_bind_pw' => 'somepass', 'search_filter' => '(&(objectClass=inetOrgPerson)(|(uid=%u)(mail=%fu)))',
This would cause Roundcube to perform two bind operations against the global address book (one of possibly multiple address books in $rcmail_config['ldap_public']), before the UI is populated with information (using the 'filter' setting and other standard parameters);
user to bind as (using service account credentials, in this case, as anonymous searching is not allowed),
Neither should interfere with your CAS authentication, but of course the question is whether the user / Roundcube could be made to bind to LDAP.
Kind regards,
Jeroen van Meeuwen
Hi, Sorry, but maybe I don't understood all, but I wil try to complete/explain our case with example of configuration.
Le 05/12/2012 19:48, Jeroen van Meeuwen (Kolab Systems) a écrit :
On 2012-12-05 18:23, Julien Gribonvald wrote:
Thanks for your response,
The things is that we doesn't use LDAP auth but the CAS auth. After we doesn't permit user auth and access to ldap so I don't think that we can use your example if I understood your ldap configuration.
My example wasn't so much related to the user authentication itself as it was to authorization within LDAP.
I was indeed assuming the user was required to bind to LDAP (as themselves / with their own credentials) - I figured it was a reasonable assumption as otherwise all information contained in the LDAP tree is public / commonly available to all, but perhaps it wasn't ;-)
I'd still like to learn if my description of your functional requirement was indeed somewhat correct / accurate:
We don't bind the user, we use only a generic user account wihch is configured to access to somes attributes needed for the application.
At the login we get from the CAS auth the user uid which help to get ldap attributs from this config :
$rcmail_config['ldap_public']['All'] = array( .... 'user_specific' => true, 'base_dn' => 'ou=people,dc=our_domain,dc=fr', 'bind_dn' => 'cn=service_user,ou=administrateurs,dc=our_domain,dc=fr', 'bind_pass' => 'password', 'writable' => false, 'LDAP_Object_Classes' => array('top', 'inetOrgPerson'), 'required_fields' => array('cn', 'mail'), 'LDAP_rdn' => 'cn', 'ldap_version' => '3', 'search_fields' => array('mail', 'cn'), 'name_field' => 'cn', 'email_field' => 'mail', 'surname_field' => 'sn', 'firstname_field' => 'givenName', 'sort' => 'cn', 'scope' => 'sub', 'filter' => '(|(objectClass=ENTPerson)(mail=*))', 'fuzzy_search' => true, 'sizelimit' => '3000', 'timelimit' => '10000', );
$rcmail_config['new_user_identity_addressbook']='All'; $rcmail_config['new_user_identity_match'] = 'uid';
My configuration would be to use a special multivalued user attribute in a filter to specify an addressbook depending of this value. The attribute isn't in a LDAP subcontext, only in index.
On 2012-12-05 18:13, Jeroen van Meeuwen (Kolab Systems) wrote:
Are you saying that you need, for example, a filter of:
(&(objectclass=inetorgperson)(location:$branch_office_1))
for somebody that logs in that has an LDAP attribute 'location' set to '$branch_office_1', or something along similar lines?
That said, I reckon Roundcube still logs in to an IMAP server using some sort of set of credentials, correct? Could these credentials not also be used to "log in" (bind) to LDAP?
IMAP also use CAS auth in our context, and the mail box is associated to the uid given by CAS, i don't think that this service make a search on ldap. Only the dovecot make ldap request to look for the match between the mail adresse and user uid. For the mail we have a special LDAP mail schema :
mail_drop} where virtual_domain_name is the mail domain, mail_alias is the user login used for the mail adress (part before the @) and mail_drop (multivalued) where to send the mail ie the uid and maybe other user mail address where to forward.
Please allow me to state a snippet of (stock, off-the-shelf) Roundcube configuration that we use:
/etc/roundcubemail/main.inc.php:
'user_specific' => true, 'base_dn' => 'dc=example,dc=org', 'bind_dn' => '%dn', 'bind_pass' => '', 'search_base_dn' => 'dc=example,dc=org', 'search_bind_dn' => 'uid=some-service-account,ou=Some OU,dc=example,dc=org', 'search_bind_pw' => 'somepass', 'search_filter' => '(&(objectClass=inetOrgPerson)(|(uid=%u)(mail=%fu)))',
This would cause Roundcube to perform two bind operations against the global address book (one of possibly multiple address books in $rcmail_config['ldap_public']), before the UI is populated with information (using the 'filter' setting and other standard parameters);
- A bind operation in order to allow searching for the entryDN of the
user to bind as (using service account credentials, in this case, as anonymous searching is not allowed),
- A bind operation with the entryDN that is found for the user.
Neither should interfere with your CAS authentication, but of course the question is whether the user / Roundcube could be made to bind to LDAP.
My question is more like how to get the user attribute needed to compose my adressbook filter depending my config, I think I'm more in the first case, but maybe i missed something that can permit to get directly user attributes value and to place it in a filter for addressbook.
Regards, Julien