No need to account for revisions that are not current when calculating stokens
because those, by definition, are not the latest ones, and therefore won't have
the most recent stokens.
This becomes a problem when collections have many associated revisions.
DJANGO_STATIC_ROOT is required in order to run `collectstatic` in
a packaging environment - manually specifying it as an environment
variable should always override any config files that may exist.
The way were were doing it was implicitly sorting the query items and it
was causing millions of items to be sorted (even though the result should
only have one) making it slow.
By switching away from `get()` and `first()` we are telling django to
not try to sort.
This commit adds code to allow users that prefer to do user management
via LDAP to do so. Since Etebase does not store the password (proof) in
a LDAP compatible fashion, we compromise and instead two checks: One while
registering an account to see if the username is the LDAP directory and
one whenever the API is accessed. To prevent too many LDAP requests, the
result of the request is cached for an configurable amount of hours.
Make sure you have python-ldap installed and can successfully import
ldap. Then, if you use the easy config, add the following to your
config:
```
; [...]
; Regular etesync configuration
[ldap]
bind_dn = <Your LDAP "user" to bind as. See Note 1>
bind_pw = <The password to authenticate as your bind user>
; Or if you have the password in a file:
; bind_pw_file = /path/to/the/file.txt
server = <The URL to your LDAP server>
search_base = <Your search base>
filter = <Your LDAP filter query. See Note 2>
; In case a cache TTL of 1 hour is too short for you, set `cache_ttl` to
the preferred
; amount of hours a cache entry should be viewed as valid:
; cache_ttl = 5
```
With this config, I am able to make the EteSync server check with my
LDAP server if a user should be able to login or register.
Note that if a user is allowed to login or register, the password of the
LDAP user will be ignored. This LDAP patch is nothing more than an
additional check before the actual authentication.
A successful LDAP check will be cached, if not configured (correctly),
for one hour, after which the LDAP query will be performed again.
Note 1: This commit only works with a bind user
Note 2: The query must be specified. If an LDAP query returns more than
one or no result, then the authentication fails. If your query needs to
include the username that currently tries to perform a login or
registration, you can use %%s, which will be subsituted for the used
username.
