Bcrypt allows a maximum of 72 bytes. This is part of the algorithm and not something we could change in Vikunja. The solution here was to restrict the password during registration to a max length of 72 bytes. In the future, this should be changed to hash passwords with sha512 or similar before hashing them with bcrypt. Because they should also be salted in that case and the added complexity during the migration phase, this was not implemented yet.
The change in this commit only improves the error handling to return an input error instead of a server error when the user enters a password > 72 bytes.
Resolves https://vikunja.sentry.io/share/issue/e8e0b64612d84504942feee002ac498a/
This PR adds reactions for tasks and comments, similar to what you can do on Gitea, GitHub, Slack and plenty of other tools.
Reviewed-on: #2196
Co-authored-by: kolaente <k@knt.li>
Co-committed-by: kolaente <k@knt.li>
This change adds the ability to sync teams via a custom openid claim. Vikunja will automatically create and delete teams as necessary, it will also add and remove users when they log in. These teams are fully managed by Vikunja and cannot be updated by a user.
Co-authored-by: kolaente <k@knt.li>
Reviewed-on: #1393
Resolves #1279
Resolves https://github.com/go-vikunja/vikunja/issues/42
Resolves https://kolaente.dev/vikunja/vikunja/issues/950
Co-authored-by: viehlieb <pf@pragma-shift.net>
Co-committed-by: viehlieb <pf@pragma-shift.net>
Cache was not working correctly, added more complexity and actually made response times slower. Because of this, I'm removing all cache options until we figure out a better solution.
Resolves vikunja/api#1496
Resolves vikunja/api#907
# Description
This PR adds API routes to create and manage caldav tokens. These tokens can be used instead of a user password - required for users who are using external auth providers and don't have a password.
Fixes#842
Frontend: vikunja/frontend#1186
Co-authored-by: kolaente <k@knt.li>
Reviewed-on: vikunja/api#1065
Instead of naeveily checking for all reminders due in the next minute, we now check all reminders in all time zones in the next minutes. This essentially means checking for reminders due in the next 14 or past 12 hours. We then check for each user who would receive a reminder from that result if it is actually due in their time zone.
This should prevent issues where users would get the reminder in the time zone of their server, not in their own.
Co-authored-by: kolaente <k@knt.li>
Reviewed-on: vikunja/api#1092
Co-authored-by: konrad <k@knt.li>
Co-committed-by: konrad <k@knt.li>