No description
Find a file
2024-12-20 21:35:33 +01:00
src Perform destructive actions only when ACTUALLY_BAN_USERS=true 2024-12-20 21:35:33 +01:00
static Add a new /classified page that allows editing classifications 2024-12-18 17:06:45 +01:00
templates Add a new /classified page that allows editing classifications 2024-12-18 17:06:45 +01:00
.gitignore . 2024-12-18 08:36:18 +01:00
Cargo.lock Notify users by email when locking their account (wip: error handling) 2024-12-20 10:18:37 +01:00
Cargo.toml Notify users by email when locking their account (wip: error handling) 2024-12-20 10:18:37 +01:00
model.json Fix redirect response on POST by explicitly sending the page URI 2024-12-19 12:49:16 +01:00
README.md Perform destructive actions only when ACTUALLY_BAN_USERS=true 2024-12-20 21:35:33 +01:00

spam management for forgejo

Usage

  • create an API token for your admin account, and write it in an api_token file at the root of the repo
  • remove model.json if you want to start with no pre-existing model of what is spam or not. Or keep it to use the current classifier. The file gets updated when using the tool: the classifier learns from spam/legit decisions and should get progressively better at identifying spam.
  • run: cargo run
  • classify users as spam/not spam. Right now the classification is stored locally in db.json, no concrete action is taken. (Ultimately we will want to lock/delete accounts, etc.)

Configuration

Forgery reads the following environment variables:

  • ACTUALLY_BAN_USERS: define it (e.g. to true) to actually lock user accounts, send notification emails and eventually delete user accounts. If not defined (the default), no actual action is taken, spammers are only listed in the database. The variable should be set in production, but probably not for testing.

Environment variables that are relevant when ACTUALLY_BAN_USERS=true:

  • SMTP_ADDRESS: address of the SMTP relay used to send email notifications
  • SMTP_USERNAME: SMTP username
  • SMTP_PASSWORD: SMTP password

Todos

  • discuss the current design choices for when locking the account/sending a notification email fails. (Current behavior is to periodically retry, avoid deleting if the account could not be locked, but delete the account after the grace period even if the email could not be sent…)
  • add backend to store data on garage instead of local files
  • replate the api_token file with a better mechanism: oauth maybe?
  • improve error handling