Fix add-member support for calendars
Change the add-member parameter to add_member to match the name of the global variable name. Otherwise the global variable was always unset and the generic POST handler handled the request instead of the PUT handler for vcalendars.
Make sure to return a Location header when adding a vcalendar using add-member POST.
See merge request !14
Add component parameter to content-types headers and getcontenttype properties
This allows clients using sync-collection requests to filter the results quickly by just looking at the content-type without having to parse the calendar data.
See merge request !15
Basic Auth Bugfix
Bugfix on Basic Auth username/password split.
Basic Auth uses a colon (":") to separate the username and password values. Using the php 'explode' function on this string without limiting the number of substrings returned can truncate the users password if it contains a colon.
By limiting the explode to 2, we get back the username and whatever else is left as the password (hence not truncated).
See merge request !12
Fixed broken import function (fixes#38)
Removes a doubled code block introduced in commit 8e60bb3124e2cc4ff09f388e520f3b6935ffc733 causing imports to fail after the first one.
See merge request !13
Basic Auth uses a colon (":") to separate the username and
password values. Using the php 'explode' function on this
string without limiting the number of substrings returned
can truncate the users password if it contains a colon.
By limiting the explode to 2, we get back the username and
whatever else is left as the password (hence not truncated).
to control whether the obsolete Scheduling property
"calendar-free-busy-set" is populated during a PROPFIND. For Issue #31,
Database Performance Improvements.
Fix current-user-principal
The RFC 5397 (http://tools.ietf.org/html/rfc5397) states that current-user-principal should return the principal URL for the current user, the one who is currently authenticated.
DAViCal answers with the principal URL for the owner of the resource right now, so this is a simple patch to fix this behaviour.
See merge request !9
supported values:
false/unset => keep these resource active
true => never show these resources
array('User-Agent'=>'#regex1#', 'X-Client'=>'#regex2#') => if a client sends "User-Agent" header which matches the regex1 OR "X-Client" header which matches regex2 then do not show these resources
supported values:
false/unset => always show bound collections
true => never show bound collections
array('User-Agent'=>'#regex1#', 'X-Client'=>'#regex2#') => if a client sends "User-Agent" header which matches the regex1 OR "X-Client" header which matches regex2 then all bound collections are hidden
new option: if set to PHP regex string then hide_TODO is enabled if the client
user-agent string matches the regex for example:
$c->hide_TODO='#^iOS.*dataaccessd.*#';
will hide all todos from non-owner/non-admin users for iOS devices
'calendar_components' sets the
'urn:ietf:params:xml:ns:caldav:supported-calendar-component-set' property for
the calendar collection (used to distinguish between different type of calendar
collections, for example: todo and event calendars) the value must be a
non-empty array; allowed values: 'VEVENT', 'VTODO', 'VJOURNAL', 'VTIMEZONE',
'VFREEBUSY', 'VPOLL', 'VAVAILABILITY'
for example:
array('VEVENT')
array('VTODO')
array('VEVENT', 'VTODO')
null or undefined => all default calendar components are supported - see
$c->default_calendar_components
NOTE: if you want to change the value of this property later, you need to do
it directly in the database ("property" table) or in the client software!
'default_properties' sets custom properties for the collection in the
"property" table the value must be a non-empty associative array of
key => value pairs (key = property name, value = property value) for example
(set the calendar color property used by Apple and other clients):
'default_properties' => array('http://apple.com/ns/ical/:calendar-color'=>'#ff0000'),
null or undefined => no property is stored in the database
NOTE: if you want to change the value of this property later, you need to do
it directly in the database ("property" table) or in the client software!
If the ldap driver is not valid, the error messages were not printed.
There was just "Couldn't contact LDAP server for authentication" - But
why?
This commit adds a print loop for all messages from the global
$c->messages message array.
As I could see at other locations in the code, the ldap driver instance
can be invalid. And if the instance is invalid, the getStaticLdap()
function gets called again. Caching would prevent the function from
retrying to initiate the ldapDrivers object.
This commit adds conditional caching: only if the ldap driver instance is
valid, the object gets cached. This ensures that a retry with this function
would really try to create a new ldapDrivers object and not simply
return the (invalid) cached one.
There was already a variable to cache the ldap driver instance, and a
check if this variable was already set was there, too! But there was no
code to return the cached instance if the function gets called twice!
Maybe this was simply forgotten...
