Add a new 'sasl' option to the LDAP driver, which invokes
ldap_sasl_bind() instead of ldap_bind().
This allows authenticating to LDAP using the GSSAPI (kerberos) or
EXTERNAL mechanisms, rather than a bindDN and password.
Note that for GSSAPI binds, PHP needs access to valid kerberos
credentials (for example, by setting the KRB5CCNAME environment variable
for the PHP process).
Tested with OpenLDAP/Heimdal kerberos, but should also work with Active
Directory.
Resolves this warning in PHP 7.4.0:
Deprecated: bindec(): Passing null to parameter #1 ($binary_string) of type
string is deprecated in /usr/share/davical/inc/ui/principal-edit.php on line
412
Resolves this warning in PHP 8.2:
Warning: Undefined array key 0 in /usr/share/davical/inc/iSchedule.php on
line 218
Warning: Trying to access array offset on null in
/usr/share/davical/inc/iSchedule.php on line 218
PHP 8.2.0 has deprecated dynamic creation of properties.
This kind of warning message is displayed:
Deprecated: Creation of dynamic property DAViCalSession::$login_failed is
deprecated in /usr/share/awl/inc/Session.php on line 153
There is potential to leak information when viewing the principal
page for another principal. I think it makes more sense to just
not include all of this information unles the user can change the
principal.
Previously PHP was escaping things like ampersands, which then caused
us to have broken URLs.
These aren't displayed anywhere in the UI, so no need to encode them anywhere.
Closes#314.
Previously something like this would be logged if debugging is enabled:
davical: LOG: Principal: Query: DBGQ: SELECT * FROM collection WHERE user_no= :user_no
davical: LOG: Principal: Query: DBGQ: ":user_no" => ""
davical: BUG: :DAViCal Fatal Error: [42883] SQLSTATE[42883]: Undefined function: 7 ERROR: operator does not exist: integer = boolean\nLINE 1: SELECT * FROM collection WHERE user_no= FALSE\n ^\nHINT: No operator matches the given name and argument types. You might need to add explicit type casts. at /home/puck/work/Calendar/awl/inc/AwlDatabase.php:94
And this would be returned as a response:
DAViCal Fatal Error
user_no doesn't get set when construction the Collection for the external
bind, so, just handle that instead of sending the empty string to the
database as a user_no.
Modify the tests from ccc7e182ba4cbfba66a4fe96e1c0620e46390b95 to tickle the
bug.
Closes#175.
This changes 48c6512a70740c403027b66e9d609e9b871d29c0, in Eric's commit it
needs a flag to go fetch the record and apply the mapping to find the
username field. This approach looks for a telltale that this is DN (naively
an "=") and then either grabs the first element from the DN if the username
attr matches or fetches the entry from LDAP.
There have also been attempts in the past to special case uniqueMember and
to add a group_member_dnfix config option.
This should handle the cases where people use uid/cn/whatever for the
username.
The logic actually handled updated group details, but only new groups were
being passed in. This will cause changes to what is being used for the
fullname to flow through.
This is to be consistent with group_mapping_field. The code is backwards
compatible with mapping_field.
In sync_LDAP_groups assign user_mapping once, not for every group.
Usinger "username" for the group name is confusing and misleading. Just
use name, but support our users who still have username.
We don't use fullname, drop it from the example.
The phpversion check was backwards. For PHP >= 5.4.0 we should be
using session_status() === PHP_SESSION_ACTIVE not < 5.4.0.
But in fact, we only support >= 5.4.0, so this check is now redundant.
The RepeatRuleDateTime constructor extracts the date's time zone then
passes it to the parent class DateTime. Because PHP's DateTime has full
support for time zones, it compensates for them when parsing a string.
Normally this isn't a problem, because the opposite occurs when a
DateTime is converted back into a string; the two adjustments cancel
each other.
Davical often converts a time to UTC by negating the time zone offset
and adding it to the underlying DateTime (keeping the time zone intact).
A problem occurs when the result is on the other side of a daylight-
saving-time transition. In that case the adjustments do not cancel and
an incorrect time string is returned.
This bug is tricky because the problem doesn't manifest during the DST
transition iself, but hours earlier or later depending on the original
time zone. For example, 2022-03-12T18:30:00-08:00 (America/Los_Angeles)
is 2022-03-13T02:30:00Z. Since 2022-03-13 is a 23-hour day in the Los
Angeles time zone (the 2AM-3AM hour is skipped) this becomes
2022-03-13T03:30:00-07:00 after adding the negated offset. FloatOrUTC()
would strip the new offset and simply return "20220313T033000".
To allow for correct expansion of recurring confidential information
we also need to retain EXDATE, RECURRENCE-ID and SEQUENCE, otherwise
client side expansion may well be wrong.
Closes#291
