- Update docstring for optional MD5-APR1/BCRYPT support via passlib.
- Support the "md5" and "bcrypt" htpasswd_encryption config values.
- Conditionally import the required passlib components if either
"md5" or "bcrypt" is requested in the configuration file.
- Test bcrypt backend availability upon import.
- First define verification functions, then conditionally import
external dependencies.
- Consolidate: use context manager for reading credential file.
- Consolidate: save one call to strip() while parsing.
- Consolidate: break long lines, clarify comments and docstrings.
- Consolidate: use verification function mapping for improving maintainability.
We should burn PEP 235, bicameral scripts, encodings, Python2/3 compatibility,
Windows, MacOS X, filenames, unicode (including composite characters), and the
whole world. And LF/CR too, of course.
Let's recreate a language relying on only two characters. Anyone interested?
If I do REPORT requests, the following line would raise a KeyError:
items = [collection.items[name]]
Wrapping it with a try-except block obviously fixes that issue.
At least for REPORT requests, Radicale now also returns proper HTTP
status codes when items or just its properties couldn't be found.
This is required as we do not want .props files to be created for nodes,
otherwise they'll stop being considered as nodes, which will break
discovery of calendars.
This fixes https://github.com/Kozea/Radicale/issues/208
Fix#196
The way to do collection discovery described in
http://stackoverflow.com/a/11673483 doesn't work well with Radicale:
1. current-user-principal returns /user/calendar.ics/
2. PROPFINDs asking for calendar-home-set will return the URL that was
used in the request, which is still /user/calendar.ics/
3. The final PROPFIND with Depth: 1 is supposed to list all collections,
but because the request is done with a collection URL, Radicale returns
the items for the "calendar.ics" collection which might or might not
exist.
