- Feb 17, 2022
-
-
Julian authored
The generation now happens in a subquery inside the INSERT statement instead of separate client-managed query. This should also reduce the risk of race conditions. Service and non-service users may now use the same UID range.
-
- Feb 16, 2022
-
-
Julian authored
-
Julian authored
The command replaces all existing mechanisms for deleting expired objects. It should run at least daily. The Debian package includes a corresponding cron job. Ratelimit events now use UTC timestamps instead of localtime. On upgrade all past ratelimit events are cleared.
-
- Feb 13, 2022
-
-
Julian authored
Argon2 is a modern password hashing algorithm. It is significantly more secure than the previous algorithm (salted SHA512). User logins with Argon2 are relativly slow and cause significant spikes in CPU and memory (100MB) usage. Existing passwords are gradually migrated to Argon2 on login.
-
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.
-
- Feb 04, 2022
-
-
Julian authored
Previously the getmails API endpoint did not match "receive_address" values case-insensitivly like it did pre-v2. To solve this independent of database collations, all existing mail receive addresses are converted to lower-case and new/changed receive addresses are constraint to ASCII lower-case letters, digits and symbols.
-
- Feb 01, 2022
-
-
Julian authored
The options were introduced to cleanly handle LDAP user connections. Since LDAP support is now gone and hence user connections are gone too, these options are no longer necessary. While the options may be useful in other cases, we cannot continuously test them and so we are removing them for now.
-
- Dec 11, 2021
-
-
Julian authored
Closes #127
-
- Dec 03, 2021
-
-
Julian authored
This change is going to be backported to v1.x.x to have a good migration path. Bearer auth with API_CLIENTS config key is deprecated and planned to be removed in v2.0.0.
-
- Oct 05, 2021
-
-
Julian authored
-
- 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 13, 2021
-
- Sep 10, 2021
-
-
Julian authored
-
Julian authored
Existing links continue to work. However support for legacy links (without id) is deprecated and will be removed in the future.
-
Julian authored
This affects mail verification and password reset links. Existing links continue to work. However support for legacy links (without id) is deprecated and will be removed in the future.
-
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 08, 2021
-
-
Julian authored
-
- Sep 05, 2021
-
-
Julian authored
Fixes #104. Replaced "group" keyword argument for login_required with "permission_check". Most views already define a *_acl_check function that returns whether the current user has the required permissions for use with register_navbar. The same function can now be passed to login_required as the "permission_check" argument. Differenciated login and selfservice access permissions. Previously ACL_SELFSERVICE_GROUP was required to login. Now ACL_ACCESS_GROUP is required to login and ACL_SELFSERVICE_GROUP is required to access selfservice functions (and to use role-granting invite links). A user with just ACL_ACCESS_GROUP can now login, access the services overview page and authenticate with OAuth2 services he has access to, but not change his user attributes, password or roles/permissions.
-
- Sep 04, 2021
-
-
Julian authored
The test cases effectivly tested if the user_acl_check works which is already covered by other test cases.
-
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.
- Sep 02, 2021
-
-
Julian authored
flask_oauthlib is no longer available in Debian Bullseye. It is only a wrapper around oauthlib, which is still available. While this change does increase the OAuth2 code size, it achieves compatability with both Debian Buster and Bullseye. Aside from error handling, this change has no noticable effects on OAuth2.0 clients. In terms of error handling, a few cases that were not properly handled before now return appropriate error pages. Fixes #101
-
- Aug 30, 2021
-
-
Julian authored
Prior to this change user passwords were not validated on change aside from their length, but validated on login/bind by ldap3 with SASLprep. Instead of using SASLprep on password change, this change restricts passwords to 7-bit ASCII without control characters. Control characters are forbidden by SASLprep. Multi-byte characters are uncommon in password, especially in those generated by password managers. This ensures that passwords are always SASLprep-safe without implementing the rather complex SASLprep algorithm. It also allows us to fully describe the alphabet restrictions in the relevant forms. Fixes #100
-
Julian authored
Ldap3 raises LDAPSASLPrepError on bind if the password contains characters forbidden by SASLPrep (string preperation/normalization algorithm for user names and passwords). Examples are carriage return ("\r") or newline ("\n") characters. See #100.
-
- Aug 14, 2021
-
-
Julian authored
-
- Jul 30, 2021
-
-
Julian authored
-
- Jul 29, 2021
-
-
Julian authored
-
- Jul 26, 2021
-
-
Julian authored
For password reset this prevents circumventing the loginname/email-based ratelimit.
-
- Jul 23, 2021
-
-
Julian authored
-
- Jun 22, 2021
-
-
Julian authored
-
- Jun 17, 2021
- Jun 13, 2021
-
-
Julian authored
-
- Jun 12, 2021
-
-
Julian authored
Co-authored-by:
psy <psy@darmstadt.ccc.de>
-
- May 21, 2021
-
-
Julian authored
-
- May 15, 2021