- Feb 13, 2022
-
-
Julian authored
Previously User used salted SHA512 with OpenLDAP-style prefix syntax and Signup used crypt. Both models had their own hashing and verification code. Now both use OpenLDAP-style syntax with support for all traditional formats including crypt. Salted SHA512 is used for new User and Signup passwords. Existing Signup objects are migrated to the new format and remain functional. User passwords now support gradual migration to another hash algorithm when it is changed in the future. This code is planned to be used for database-stored API and OAuth2 client secrets.
-
- Oct 02, 2021
-
-
Julian authored
* Removal of ldapalchemy and LDAP mocking support * Removal of dependency on ldap3 (except for the migration) * Remaining "LDAP_<name>" config keys are renamed to "<name>" * Web interface to create, edit and delete groups * Consistent foreign key, cascading and nullable configuration on all models * User/Group.dn is replaced with numeric User/Group.id * User.uid is renamed to User.unix_uid (to differentiate with new User.id) * Group.gid is renamed to Group.unix_gid (to differentiate with new Group.id) * All User/Group/Mail related routes now use the database ids instead of uid/gid/dn * PasswordToken/MailToken now reference users directly instead of storing loginnames The database migration (optionally) uses the v1 config keys to connect to an LDAP server and to import all users, groups and mail forwardings.
-
- Sep 10, 2021
-
-
Julian authored
Existing invite links continue to work. However support for legacy links (without id) is deprecated and will be removed in the future.
-
- Sep 04, 2021
-
-
Julian authored
Prior to this change permission errors (i.e. the user is logged in but does not have a required group) were reported with flash('Access denied') and a redirect to the selfservice index page. This causes two problems: The error is reported with HTTP status 301/200 which is difficult to check for in tests. This can also cause redirect loops as soon as the selfservice uses more differentiated permission checks (see #104). With this change a dedicated error page is displayed in place the requested page and the HTTP status 403 is returned. This is implemented with flask's errorhandler concept for 403.
-
- Jul 26, 2021
-
- Jun 22, 2021
-
-
Julian authored
-
- Jun 17, 2021
- Jun 13, 2021
-
-
Julian authored
-
- May 15, 2021
-
-
Julian authored
-
- May 11, 2021
-
-
Julian authored
-
- May 01, 2021
-
-
sistason authored
-
- Mar 14, 2021
-
-
Julian authored
-