View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001058 | SOGo | Web Calendar | public | 2010-12-16 22:39 | 2010-12-28 19:55 |
Reporter | janfrode | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Product Version | 1.3.4 | ||||
Summary | 0001058: sogo searching LDAP when sharing calendar, even with isAddressBook = NO | ||||
Description | When we try to share calendars, and enter an email address We haven't configured any shared address books, only given
| ||||
Tags | No tags attached. | ||||
When you search for "shared calendars", it's perfectly normal that the LDAP sources is scanned because it search for users, not "contacts". So this is the normal behavior. If your LDAP process consumes too much CPU, look at indexing the right attributes to make the search immediate and try to limit the number of returned entries (a SOGo configuration parameters) from your LDAP server in case someone search for "Bob" and you have 10 000 "Bob" in your LDAP server. |
|
Being an ISP we shouldn't let anything list our users email addresses.. So is there any way of disabling this feature ? Ideally it should only be looking in the user's private address books. I believe we have most fields indexed in ldap, so maybe the problem is that the searches are matching and returning too many users. What's the setting for limiting the number of returned entries ? |
|
To limit the number of returned results, use SOGoLDAPQueryLimit Right now there's no way to disable this feature. Sharing calendars/addressbooks/mails is a feature available to all users and all users part of the system are exposed to it. It would make sense to limit it only to the user's address books but then again, only for the "local" users as it won't make any sense to "share" a resource with an external user that way. External users can subscribe to the ics or XML version of a calendar based on the user's (or system's) access rights on that resource. |
|
You can also set SOGoLDAPQueryTimeout to limit the time it'll take to return the results. |
|
Found the query now, and see we would need to index a few new fields for this to work. We have no index on givenName, sn, displayName or telephoneNumber, and probablt don't want these searchable either. Best would be if we could remove the "Subscribe to calendar" (and similar functionality), alternatively require the search to be a pure email address lookup. i.e. change: SRCH base="o=isp,o=example,c=com" scope=2 filter="(|(givenName=janfrode)(sn=janfrode)(displayName=janfrode)(mail=janfrode)(telephoneNumber=janfrode))" to: SRCH base="o=isp,o=example,c=com" scope=2 filter="(|(mail=janfrode))" Is there also no way of disabling the whole "Subscribe to calendar" function/button, leaving "Subscribe to web calendar" as the only option for subscribing to other people's calendars ? I guess we will need to figure out all places where account-database is used for other functions than authentication, and rip out if we're going to use SOGo. For sharing to specific users, it would be great if the sharing/access was based on a unique token in the URL, and thereby possible to use outside of the SOGo user database. |
|
For the search filter, look at : http://www.sogo.nu/bugs/view.php?id=1028 We will likely include that patch. For removing the "Subscribe to calendar" - you could modify the templates (.wox files) to achieve this. Don't forget you need to restart sogod when you modify those templates. |
|
See 0001028 for a related fix. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2010-12-16 22:39 | janfrode | New Issue | |
2010-12-16 23:07 | ludovic | Note Added: 0001953 | |
2010-12-16 23:29 | janfrode | Note Added: 0001954 | |
2010-12-16 23:37 | ludovic | Note Added: 0001955 | |
2010-12-17 00:01 | ludovic | Note Added: 0001956 | |
2010-12-17 08:51 | janfrode | Note Added: 0001958 | |
2010-12-17 16:44 | ludovic | Note Added: 0001959 | |
2010-12-28 19:55 | ludovic | Note Added: 0001976 | |
2010-12-28 19:55 | ludovic | Status | new => closed |
2010-12-28 19:55 | ludovic | Resolution | open => no change required |