On That Okta LDAP Bug
A quick explanation of the Okta AD/LDAP DelAuth bug that was being shared around, and the importance of sensible defaults.
A quick explanation of the Okta AD/LDAP DelAuth bug that was being shared around, and the importance of sensible defaults.
This post discusses topics some may wish to avoid: terminal illness, hospice care, death, and Japanese visual novels.
There are two programming principles that I hold dear to my heart: the principle of least surprise and provide sensible defaults. I’ve recently been working within the GraphQL ecosystem, and the number of violations of both here has frustrated me. This will be a little bit ranty.
I’ve been managing a fully remote, fully distributed team, covering timezones from UTC-8 through UTC+10, for the last couple of years. Through that time, I’ve learned a lot on organising work, interpersonal relationships, and ultimately how to overcome a lack of promximity to my reports.
At $WORK
, we have a case where we have implemented an event trigger to prevent customers from dropping an extension. As this extension is part of contrib
and normally installed by users, we can’t prevent them from dropping it normally. However, event triggers can only be created by superusers, so a pg_dump
of the database creates a dump that can’t be restored by a non-superuser. To solve this, lets implement a custom pg_dump
that optionally excludes event triggers.
You can see the following implementation in this diff on my fork of the Postgres repository.