As mentioned in discord:
Hey @everyone, sorry for pinging everyone but it's for an important matter I would like to inform everyone about. Keeping tinyauth stateless is becoming increasingly hard and it is creating security holes. I believe it's time to introduce a simple statefull tinyauth with a simple sqlite database for session management. This would of course require a docker volume and a breaking update but I think it's worth it as it would skyrocket the security of tinyauth as well as allow for the invalidation of sessions server-side. The cookie will have to store minimal info consisting of a simple UUID instead of the mess that we have right now. Let me know what you think either in #💻・development or by reacting to this message.
Keeping tinyauth stateless is hard and insecure, that's why we should move to a simple storage backend to store sessions. The idea is to move all the cookie information in a database row and assign a UUID to this row. Then the cookie get's the same UUID. In the authentication flow if the UUID the cookie contains matches with a row of the database, we use the user as usual, if not we assume the session is invalid. For the database we can use Gorm alongside a native SQLite driver to avoid the need for CGO.
As mentioned in discord:
Keeping tinyauth stateless is hard and insecure, that's why we should move to a simple storage backend to store sessions. The idea is to move all the cookie information in a database row and assign a UUID to this row. Then the cookie get's the same UUID. In the authentication flow if the UUID the cookie contains matches with a row of the database, we use the user as usual, if not we assume the session is invalid. For the database we can use Gorm alongside a native SQLite driver to avoid the need for CGO.