We also use a locally set password (aka a pepper) to ensure that the contents
of memcached isn't sufficient to perform dictionary attacks on the cached
credentials.
This is to tickle my suspicion of the bug as reported by Thorsten Marquardt
in https://sourceforge.net/p/davical/mailman/message/58766531/ with this
error message reported:
Exception [0] ldap_get_attributes(): Argument #2 ($entry) must be of
type LDAP\ResultEntry, false given
At line 718 of /usr/share/davical-master/inc/drivers_ldap.php
You need to look in 3da860e5d5e732c2dedb62a73c76608a2b7098a4 for that line
number as I've just made some improvements to the code.
I have also improved the SQL to check if the users have been added, and
discovered that the result file *did not* have them. This test was failing
due to the test config file looking for memberUid, not member. Also, fix
that.
This allows us to have more complex test files where an action is taken, then
we test something, then another action is taken, etc.
Changes to test files are required so that URL is defined after all the
required settings are set.
Changes to the result files are either whitespace changes due to above logic
changes, or printing out a SQL Result header before each result. I figured it
was useful.
Test that other users can't delete:
- collections
- tickets
- bindings
No significant change, just return an error message rather than assume that
things worked.
There is now a Perl script that'll generate tests and result files to a
wide variety of dates. From this we currently don't support < 1 AD or >
9999 AD.
run_regressions is modified to remove the UNTIL option as I want to use a
character after the test number to allow "subtests".
postgresql is fussy about dates before 1900. Add a test with a recuring
event startting before 1900.
Signed-off-by: Benedikt Spranger <b.spranger@linutronix.de>
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.
Oh, this is much easier to work with.
We can now detect the version of PostgreSQL installed and shouldn't
need to update CI just because PostgreSQL has been updated in Debian
Unstable.
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 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.
