🍄WillowMeeting 2023-12-01

Consultation with Chris Waldon


  • Stick with SQLite until and unless we need something from, say, PostgreSQL that SQLite just can't do. SQLite can scale to hundreds/thousands of users and should be more than “good enough” for now.

    • Be aware that, when running SQLite in memory for tests, operations that execute concurrent to other operations will create new, empty in-memory databases. Tests using an on-disk database, an in-memory database with that behaviour, or an in-memory database with the workaround described in the go-sqlite3 FAQ are all valid. It just depends on the context.

  • crawshaw.io has some good thoughts on SQLite



  • Use one column for the projects and a second column for the release notes, the release note button/link should un-hide (CSS) the associated release notes element. The two columns should scroll independently of each other.

Security considerations

  • Potential CSRF mitigation is a hidden form field with a generated token. Every POST request needs to include that generated token. This ensures the POST request is genuinely from our form, not from someone masquerading as our form.

  • Poke through OWASP for common web app vulnerabilities and consider how they might apply to Willow

    • Maybe look into automated webapp vulnerability tests? Something you point at an authenticated URL to check

Stateful forms

  • We currently persist state by keeping data in URL parameters. Implementing sessions could not only make the URLs cleaner, but also help solve #12. When creating the HTML template, fill a hidden form field with a generated token that the backend uses to keep track of the submitted data. If the user clicks their browser's back button and selects a different forge, the session cookie associates the new submission with the old submission that had different values.

    • At startup, spawn a goroutine to clean up expired sessions. It should last the lifetime of the app and wake up on a timer, similar to how fetching releases currently works.