Greenhouse development update 1By On
I have been striving to work on greenhouse every day. Of course, I can't always meet that standard, but I believe I've gotten more done than my activity heatmap might indicate, as I have a bad habit of working on elements and features for more than a day before I commit them.
I implemented basic registration and login with email address verification.
Some interesting notes about registration and login:
- I decided to implement my own sessions from scratch.
- I chose to implement Server-side sessions.
- Doing it myself was a bit indulgent, but I enjoyed the flexibility it gave me, because:
- HTTP Cookie Security + Email verification can be a bit of a pain point
- Have you ever registered for an account on a website, clicked the link in the verification email, only to be greeted by a login page?
- This happens because of the
SameSiteattribute on the cookie. When set to
SameSiteattribute will prevent the browser from sending the cookie on any request which is not "referred" from the same domain the cookie belongs to. So, for example, if you log into gmail and click the link, the request will be referred from
greenhouse.server.garden, and the browser won't send the cookie.
SameSite=Strictis really good at preventing CSRF (Cross Site Request Forgery) attacks, but not so good for usability when the user is trying to verify thier email address.
- I decided on a solution where I have one cookie that uses
SameSite=Laxand one cookie that uses
LaxCookieis sufficient until the user verifies thier email address, after that the normal cookie (Strict) is required.
- Best of both worlds: all relevant HTTP endpoints are protected from CSRF attacks by
SameSite=Strict(as well as other measures), however, the user experience is seamless when verifying the email address.
The admin panel requires login just like any other dynamic page on the site, except it also requires that the
TenantId of the user be equal to 1. So, the admin user is simply the first user who signed up for an account on the site. I know that admin panels are typically easy targets for the red team, but I like my authentication/authorization solution -- especially because I am using server side sessions, I think this admin panel is airtight.
I implemented a small subsystem in the admin panel which allows Greenhouse to host itself relatively easily.
This was always the plan, per the architecture diagram:
I started building a cross-platform desktop application to act as a user-friendly greenhouse client.
- I experiemented with a couple different things, various Golang-based desktop application libraries, as well as electron
- I don't like the golang-based desktop app stuff because it's simply not reliable enough to use. Too many bugs and issues. Most of the implementations require graphics acceleration to be functioning, preventing the app from being used on many virtual machines or computers that are lacking drivers.
- I don't like electron because it builds 200MB application images, even for a hello-world application, and it uses a disgusting amount of RAM.
- I settled on using fbs, the fman build system, a toolkit for building Python/QT cross platform desktop applications. It is much lighter weight, and appears to be more reliable than some of the other options.
I'm currently working out how I'm going to install the desktop application on all platforms, Mac, Windows, and Linux.
I want to have a
greenhouse-daemon application that runs in the background, not just a GUI application, because it needs to operate an embedded caddy server which will generate and store TLS keys and certificates that are used to secure HTTPS connections. Those are very sensitive files, so they should probably not be readable by just any old user on the computer! This introduces a lot of complexity when it comes to installing and running the app, the
greenhoue-daemon has to run as a special
greenhouse user so it can retain exclusive ownership over its files.
That's all for now. Stay tuned for more Greenhouse updates!