Uni-Verein 1.9.1 – Membership Status, Better Contribution Management and More Security 🧾🛡️

Published on October 23, 2026

Uni-Verein 1.9.1 brings a membership status (member or supporting member), an improved contribution management with deletion of open contributions, and a considerably extended audit log. Several security improvements come on top. If you run your own reverse proxy in front of Uni-Verein, you have to set something up once when updating, see the update notes below.

Highlights

• ⭐ Membership status (UV-58): Every member is a member or a supporting member, with a column and filter in the member list and the contribution management
• 🗑️ Delete open contributions (UV-57): Admins and financial managers can delete open contributions, e.g. for returned direct debits. Admins can restore them
• 🚫 No more billing after leaving (UV-63): Deleted members and members whose exit date has passed are no longer billed
• 📜 Extended audit log: Users, creditor data, contribution rates, contributions, mail settings, backup restore and CSV import are logged
• 🛡️ Safer login: The login lockout no longer affects all users of an account, and deleted or changed users lose access immediately

New Features

• ⭐ Membership status (UV-58): Members now have a membership status, adjustable in the form and in the CSV import as the column "Membership status" (MEMBER or SUPPORTING_MEMBER, empty = member). The member list and the contribution management get a column and a filter for it. The contribution management additionally shows the member number
• 🗑️ Delete open contributions (UV-57): Next to "Payment received" there is a trash icon that removes an open contribution after a confirmation. Contributions are soft-deleted and recorded in the audit log, admins can view them via "Show deleted" and restore them
• 📜 Audit log for all important actions: In addition to members, changes to users, creditor data, contribution rates, paid/open contributions, SMTP/mail settings, restoring a backup and the CSV import of members are logged. Passwords, IBAN/BIC and imported member data are not stored

Bug Fixes

• 🚫 Billing (UV-63): Deleted members and members whose exit date has passed are no longer considered when generating contributions and in the SEPA export. If the exit date lies in the future, the member is still billed until that date
• 👥 Member category filter (UV-61): When the member category filter is set back to "All", the list shows all members again
• 🕵️ Audit log (UV-10): Entries of deleted users are shown as "Deleted user" instead of being hidden
• 📱 App icon on Android (UV-55): The web manifest has the correct content type, and a monochrome icon is included for the themed icons of Android 16. The app icons are RGBA PNGs, the iOS icon is opaque
• 🌐 English texts of the contribution management: Because of a wrong translation key the English texts were not shown
• 📧 Update notice by e-mail: The "new version available" mail was sent to the admins every hour when one of them had no e-mail address. Such admins are skipped now
• 💶 SEPA export: The IBAN and creditor ID checks only accept the digits 0-9, so invalid IBANs can no longer break the pain.008 file

Security

• 🔐 Login lockout per user name and address: The lockout is no longer counted per account but per user name and visitor address. An attacker can therefore no longer lock known accounts like Admin out permanently for everybody. IPv6 counts per /64 network, unknown user names are locked like known ones. The state is kept in memory and reset by a backend restart. More under User Account & Security
• 🎫 Tokens are checked on every request: The login is checked against the current user and role on every request, deleted or changed users lose access immediately instead of after up to 8 hours
• 🗃️ Deleted members: Only admins can still read or change deleted members, a second deletion no longer overwrites the original deletion time
• 📝 Self-enrollment: The date of the SEPA consent is set by the server, sepaConsent is no longer accepted by POST /self-enrollment. HTML in names is encoded in system e-mails and broadcast mail placeholders, name fields are limited to 100 characters
• 🧱 Proxy trust (nginx): X-Forwarded-For is no longer accepted from the whole range 172.16.0.0/12, which allowed bypassing rate limits and the login lockout and forging the IP of self-enrollments. Only the Caddy from docker-compose-tls.yml is trusted (fixed address 172.31.250.2 in the network edge)

Logging

• 🪵 Important actions are logged: Logins, user and member management, self-enrollment, CSV import/export, contributions, SEPA exports, receipts, mail, calendar, backups, settings and background jobs end up in the backend log with IDs and the ID of the acting user, plus failed token validations, forbidden access and rate limit hits. Personal data is no longer logged
• 📊 Every request once with status and duration: /health and the duplicate REQUEST: line that leaked the calendar feed token are gone. Failed backups and restores, unhandled exceptions (with stack trace), startup information and the hourly update check are logged properly

⚠️ Update Notes

• Always update with docker-compose-update.yml, as described in the README
• A new database migration is included (AddMembershipStatusToMembers), it runs automatically at start. Existing members get the status "Member"
• Option B only (your own reverse proxy): Next to the compose file, create the folder trusted-proxies and put the address of your proxy into a .conf file in it, e.g. set_real_ip_from 192.168.1.20;. Your proxy has to overwrite X-Forwarded-For with the visitor address (nginx: proxy_set_header X-Forwarded-For $remote_addr;). Without this step all visitors share one rate limit and one login lockout. The instructions are under Get Started, and the folder is not touched by updates. Option A (Caddy) needs nothing

Why These Updates Matter

The membership status makes supporting members recognizable at a glance in the list and the contribution management, and deleting open contributions takes away the pressure of having to work around wrong or returned demands. Not billing members who have left prevents wrong bookings. The extended audit log shows traceably who changed what without storing sensitive data, and the security improvements make sure that the login lockout and rate limits really only affect attackers and not your own board.

What's Next?

Further feedback from practice is as always very welcome, feel free to use GitHub Issues. Keep checking back here!