DEV Community: Edward Fancher

Read-only user impersonation in Rails

Edward Fancher — Wed, 23 Sep 2026 16:33:05 +0000

Many support tools eventually grow a "log in as this customer" feature. Ours had a problem the usual gems don't solve. The people on the other side of the button are customers of a service containing sensitive user data. Delist My Data clients give us the history of their personal information that we will work to have taken down across the web. We want our admins to be restricted from ordering data scans or altering legal authorizations the users grant us to act as their agents for this process. We also wanted our customers to see a transparent notice that administrators had viewed their account information in this manner.

We built it and ran it in production. Last week we pulled it out into a gem called viewing_as. This post is about the decisions we made that may transfer to your app as well.

What the existing gems do

pretender is about fifty lines. It stores the impersonated user id in session[] and overrides current_user, with true_user for the real person. When all you need is the swap, it's the right tool and we'd have used it. devise_masquerade does the same thing behind a signed link, for Devise. switch_user is a dropdown for development and says so.

None of them refuse writes, or keep a log a customer could read. None of them time out or re-check anything once the session has started.

The Rails 8 authentication generator ships no impersonation at all, and the tutorials that add one keep the state in the session with an expiry and leave audit and read-only as an exercise.

Read-only, in two layers

The first layer is a before_action that refuses requests that aren't GET or HEAD while a viewing session is active. It reads the method off the Rack env, which is the same value the router dispatched on, so a POST wearing _method=get can't get a write action past it.

def refuse_writes_while_impersonating
  return unless impersonation_read_only?
  return if request.env["REQUEST_METHOD"].in?(%w[ GET HEAD ])

  render plain: "Read-only while viewing another account.", status: :forbidden
end

The second layer is for what the first can't see. A GET that calls update_column in a helper. A counter cache. A touch-on-read somebody adds next year. The action runs inside ActiveRecord::Base.while_preventing_writes, and a write that reaches it is logged at error level, because it's a bug rather than a user action.

def read_only_while_impersonating
  return yield unless impersonation_read_only?

  ActiveRecord::Base.while_preventing_writes { yield }
rescue ActiveRecord::ReadOnlyError => e
  logger.error("[ViewingAs] blocked a write: #{e.message}")
  render plain: "Read-only while viewing another account.", status: :forbidden
end

Read-only is the default, and it's a setting. A support team that fixes addresses as the customer wants the same log and the same leash with writes allowed, so c.read_only = false turns it off for everyone, and impersonate(user, read_only: false) turns it off for one session. That choice gets passed into the signed cookie when the session starts. Nothing in the browser can flip it afterwards. The log will say writable if the session is not launched in read-only mode, so the customer has an audit log.

The bug every session-based version has

Say the session expires while the admin is mid-click, or the customer withdraws consent between two requests. The natural code path drops the impersonation and carries on. The write guard now sees nobody being viewed, so it waves the request through, and current_user has quietly become the admin. The click was aimed at the customer's account. It lands on the admin's own.

In our app the routes that matter are singular resources with no id in the path, so there was nothing to fail safe on. "Withdraw authorization" at minute thirty-one would have withdrawn the admin's.

The fix is that ending a session mid-request refuses the request if it was going to write:

def finish_impersonation(kind, subject)
  end_impersonation!(kind, subject)
  return if request.env["REQUEST_METHOD"].in?(%w[ GET HEAD ])
  return if true_user.nil?

  render plain: "That session ended before this went through. Nothing was changed.",
         status: :conflict
end

This holds in writable sessions too.

Re-validated on every request

The cookie is signed. It names the target and the admin's own session, and it carries a start timestamp. On every request the gem re-reads from the database whether the admin is still an admin, whether that exact session still exists, and whether the target still exists and still permits it. A "no" from any of those ends the session and logs why. It takes effect on the next click, without anyone reaching into a browser.

Consent is a lambda the host provides. Ours checks a column the customer flips from their own account page:

ViewingAs.configure do |c|
  c.may_be_viewed = lambda do |target, _admin|
    if target.admin? then "That account is an administrator."
    elsif !target.admin_review_permitted? then "That customer has withdrawn permission for review."
    else true
    end
  end
end

The String is what the admin sees and what the refusal row in the log says.

Why a cookie and not the session

Many of our pages are cached at CloudFront. The header on every page calls authenticated?, so the sign-in check already runs on cached pages, and it costs nothing because it reads a signed cookie. Loading session[] is different. Rack writes Set-Cookie, and a response carrying Set-Cookie can't be marked public. Keeping impersonation state in the session would have quietly un-cached the whole content site to serve a feature two people use. That's the concrete reason pretender didn't fit here, and it's why the gem reads a second signed cookie instead.

The cookie is also given no expires. The timeout is enforced server-side from the start timestamp. A cookie that expired in the browser first would never be seen by the server, so the expiry would never reach the log, and the customer would see a session that started and apparently never ended.

The log the customer reads

Each row is written for the person whose account it is: "[X] started viewing your account as you see it", "Stopped viewing your account (permission ended)", "Tried to view your account and was refused". Each row records the admin's address at the time, so it outlives the admin's account, and readonly? is true once persisted so ActiveRecord can't edit it.

Using it

gem "viewing_as"

bin/rails generate viewing_as:install
bin/rails db:migrate

The generator writes three files and adds two routes. It includes the concern in ApplicationController after Authentication. It prepends a mixin into Current so that Current.user answers with the viewed account, and it renders a banner at the top of the layout. Rails 7.2 through 8.1 are on CI.

The specs are the part I'd read first. Almost every one of them is a refusal.

Parsing California's data broker registry CSV

Edward Fancher — Thu, 03 Sep 2026 15:01:38 +0000

California requires data brokers to register every year with the California Privacy Protection Agency (CPPA) and, since the Delete Act (SB 362), to disclose what they collect, who they sold it to, and how many consumer requests they handled. The result is a public table at https://cppa.ca.gov/data_broker_registry/ with one row per registered broker. In the 2026-09-01 snapshot that is 603 companies, from Acxiom to firms you have never heard of, each answering the same 77 questions. It is where people-search sites such as TruthFinder and Whitepages state, in their own words, how many deletion requests they received in 2024 and how long they took to respond.

Getting the file

The registry page has a "Download Registration Information" button that serves a file called registry.csv. We pulled it on 2026-09-01 and committed the file, byte for byte, to https://github.com/delistmydata/ca-data-broker-registry so that anyone can work from the same data without re-scraping the state site. The snippets below assume you are in that repo's root.

The shape of the file

Seventy-seven columns, and the headers are the registry's own labels, verbatim. Copy header names out of the file rather than typing them due to minor stylistic differences between columns.

The columns fall into four groups:

Identity (columns 1 to 11): name, DBA, website, contact details, address, and the URL of the broker's own privacy-rights page.
Yes/no disclosure flags (12 to 26): which sensitive categories the broker collects (minors' data, biometrics, precise geolocation, and so on) and who it shared or sold data to in the past year, including a foreign actor, the federal government, law enforcement, and a developer of a generative AI system.
Sector regulation (27 to 46): whether the broker or a subsidiary falls under the FCRA, GLBA, IIPPA, CMIA, or HIPAA, each with three free-text fields describing what is covered.
2024 consumer-request metrics (47 to 76): five families of requests (delete, know what is collected, know what is sold or shared, opt out of sale or sharing, limit sensitive PI), each with requests received, complied in whole, complied in part, denied, and mean and median days to respond.

Column 77 is a free-text comments field, and it is where most of the trouble lives.

Gotcha one: multi-line fields

Fifty-five of those comment fields contain line breaks, correctly quoted per RFC 4180. A few of the regulation description fields do too. Line-oriented tools have no idea.

$ wc -l ca_data_broker_registry_2026-09-01.csv
     866 ca_data_broker_registry_2026-09-01.csv

Subtract the header and you get 865. We did exactly that and published "865 registered data brokers" before running the file through a real CSV parser, which says 603. The same mistake bites grep -c, awk, sed and Excel's row numbers. Use a parser.

Python:

import csv

with open("ca_data_broker_registry_2026-09-01.csv", encoding="utf-8-sig", newline="") as fh:
    rows = list(csv.DictReader(fh))

print(len(rows))
print(rows[0]["Data broker name:"])

603
01Advertising Inc.

Ruby:

require "csv"

rows = CSV.read("ca_data_broker_registry_2026-09-01.csv", headers: true, encoding: "bom|utf-8")
puts rows.size
puts rows.headers.first.inspect

603
"Data broker name:"

Gotcha two: the byte order mark

The file starts with the bytes EF BB BF, a UTF-8 BOM. Both snippets above account for it (utf-8-sig in Python, bom|utf-8 in Ruby). Open it as plain UTF-8 and the first header quietly becomes Data broker name:, so row["Data broker name:"] raises KeyError on every row while the printed header list looks fine.

import csv

with open("ca_data_broker_registry_2026-09-01.csv", encoding="utf-8", newline="") as fh:
    print(repr(next(csv.reader(fh))[0]))

'Data broker name:'

Gotcha three: free text where you want categories and numbers

The state column is whatever the registrant typed. "CA" and "California" are both present, as are "NY", "New York" and " NY" with a leading space, plus "NA", "N-A", "London" and "England" from non-US registrants who had to put something in the box. Normalise before you group.

import csv
from collections import Counter

FULL = {"california": "CA", "new york": "NY", "florida": "FL", "texas": "TX",
        "illinois": "IL", "massachusetts": "MA", "virginia": "VA", "georgia": "GA"}

def state(value):
    v = value.strip()
    return FULL.get(v.lower(), v.upper())

with open("ca_data_broker_registry_2026-09-01.csv", encoding="utf-8-sig", newline="") as fh:
    rows = list(csv.DictReader(fh))

raw = Counter(r["Data broker state:"] for r in rows)
print({k: raw[k] for k in ("CA", "California", "NY", "New York", " NY")})

clean = Counter(state(r["Data broker state:"]) for r in rows
                if r["Data broker country:"] == "UNITED STATES")
print(clean.most_common(8))

{'CA': 100, 'California': 26, 'NY': 57, 'New York': 27, ' NY': 1}
[('CA', 126), ('NY', 84), ('FL', 48), ('TX', 32), ('IL', 32), ('MA', 29), ('VA', 23), ('GA', 21)]

That mapping covers the top eight; a real one needs all fifty states plus DC.

The metric columns are cleaner than I expected. In this snapshot there are no thousands separators and no decimals, so int() works on every filled cell. Two things still need handling: one broker left the deletion-request count blank, and five cells across the other request families hold small negative numbers (-1 to -4), presumably placeholders. Cast through a function that returns None for blanks, and decide what a negative count means to you before summing.

Summing the deletion requests

import csv
from statistics import median

RECEIVED = "Requests to delete - Total requests received"
MEDIAN_DAYS = ("Requests to delete - The number of days to respond "
               "substantively to a request to delete in 2024 - Median")

def num(value):
    value = value.strip()
    return int(value) if value else None

with open("ca_data_broker_registry_2026-09-01.csv", encoding="utf-8-sig", newline="") as fh:
    rows = list(csv.DictReader(fh))

received = [num(r[RECEIVED]) for r in rows]
answered = [v for v in received if v is not None]
print("answered:", len(answered))
print("total deletion requests:", f"{sum(answered):,}")
print("reported zero:", sum(1 for v in answered if v == 0))

medians = [num(r[MEDIAN_DAYS]) for r in rows if (num(r[RECEIVED]) or 0) > 0]
print("brokers with requests:", len(medians))
print("median of medians:", median(medians), "days")

answered: 602
total deletion requests: 58,031,327
reported zero: 163
brokers with requests: 439
median of medians: 5 days

So 602 of 603 brokers filled in the field. Between them they reported over 58 million deletion requests for 2024, 163 of them reported receiving none at all, and among the 439 that received at least one, the typical broker's median response time was 5 days against the 45 days the CCPA allows. The zeros deserve a second look next to the opt-out-of-sale column: several people-search operators we publish guides for reported zero deletion requests and six- or seven-figure opt-out counts in the same filing, which says more about how they classify a consumer's form than about demand.

What the metrics are and are not

Every number in columns 47 to 76 is the broker's own declaration for calendar year 2024. The CPPA does not audit them at registration. Volumes at the top of the table almost certainly include automated signals such as Global Privacy Control headers and authorized-agent submissions rather than people filling in forms, which would explain how one location-data firm can report 26 million deletion requests while a well-known people-search site reports 8. That is an inference; the file does not say. Write "reported" or "declared" in anything you publish from it, and avoid comparing two brokers' totals as if they measured the same thing.

Three things you could work out from this file

Which registrants list the most DBAs, and how many consumer-facing brands the 603 rows actually collapse into. Column 2 is free text; most registrants separate brands with semicolons, some with commas, so expect to split on both and clean by hand. What else the 32 brokers that declared sharing or selling data to a generative AI developer disclosed about themselves. And which brokers reported a median response time above the 45-day limit (there are 8), and whether their comment fields explain it.

The repo is delistmydata/ca-data-broker-registry. If you find a parsing error, a normalisation I got wrong, or a broker whose declared numbers you can check against your own records, open a GitHub issue. We will refresh the snapshot when the registry changes.

Edward Fancher is a software engineer in Seattle and the founder of Delist My Data, a data removal service that publishes free opt-out guides for the people-search sites in this registry.