DEV Community: lastmileops

Test your internal dashboard with two users before you cache it

lastmileops — Sun, 08 Nov 2026 15:43:56 +0000

A report is slow, so someone adds caching. The next person opens the dashboard and gets a result immediately. That feels like a successful optimization until they notice the first person's customer list.

An older Streamlit forum thread contains reports of users seeing one another's data and a long discussion about session state and caching. It does not establish a single diagnosis for every app in that thread. It does suggest a useful test for any internal tool that started life with one user.

Name the audience of a cached result

Two questions belong in the design review: who may read this result now, and which previous computation can supply it?

The first is authorization. The second is cache identity. Neither can substitute for the other.

Current Streamlit caching documentation says cached values are shared across users by default, distinguishes copied data from shared resources, and offers session scope. Check the options supported by your installed version. Copying a cached object protects against some shared mutations; it does not decide whether its contents belong to the current reader.

For a private report, consider the tenant, authenticated principal or effective visibility scope, requested filters, and data revision. If two users have different row-level permissions, a tenant ID alone is insufficient. A shared database connection is not proof that its query results have the same audience.

Derive these values from trusted server-side context. A caller supplying a different user ID must not acquire that user's cached report.

Keep the access check on the path that runs

A cache hit can skip the function body. An authorization check inside that body may therefore disappear precisely when a result is available quickly.

This small standard-library example demonstrates the placement of the check. It is an executable teaching example with fictional users, not a Streamlit integration or a complete access-control system:

from functools import lru_cache

grants = {("alice", "team-a"), ("bob", "team-a")}
rows = {
    ("team-a", "alice", 1): ("A-001",),
    ("team-a", "bob", 1): ("B-001",),
}

@lru_cache(maxsize=128)
def cached_rows(tenant, principal, revision):
    return rows[(tenant, principal, revision)]

def report(principal, tenant, revision):
    # Production: resolve identity and current grants on the server.
    if (principal, tenant) not in grants:
        raise PermissionError("Access denied")
    return cached_rows(tenant, principal, revision)

expected = {"alice": ("A-001",), "bob": ("B-001",)}
for order in (("alice", "bob"), ("bob", "alice")):
    cached_rows.cache_clear()
    for principal in order:
        assert report(principal, "team-a", 1) == expected[principal]
grants.remove(("alice", "team-a"))
try:
    report("alice", "team-a", 1)  # Alice's result is still cached.
except PermissionError:
    pass
else:
    raise AssertionError("A warm cache bypassed revocation")

Both users belong to the same tenant and have different rows. Local checks on Python 3.14.4 passed this exact example in both warm-up orders. A deliberately broken cache that ignored the principal returned the first user's rows to the second and failed the assertions. The correct key passed again, including the warm-cache revocation check. These are local standard-library checks, not a live Streamlit test.

Production policy can be more granular than this example. Partial row-level revocation is outside this demonstration. If a user retains access to the report while losing access to some rows, the cache identity needs the effective permission scope or a trustworthy policy revision as well. Check current authorization before returning the value, and arrange invalidation when the visibility rules change.

Data freshness is a separate decision. A TTL limits age; it does not enforce access. A source revision should identify the data actually queried. Reading a revision and then querying a moving dataset needs a consistency rule too.

Use two independent sessions

Start with two test accounts that have deliberately different visible records. Warm the cache as the first account, then request the equivalent report as the second. Reverse the order. Change a filter, change the dataset, and revoke access while the cached value remains warm.

If your app supports logout and another login in the same browser, test that transition as well. Session-local storage still needs a lifecycle: remove or rebind private values when the authenticated identity changes. A fresh browser tab is a useful test setup, not a security boundary for a badly scoped server cache.

Keep assertions about the returned records, not just the page heading or selected username. The dashboard can greet Bob perfectly while displaying Alice's rows.

Streamlit documentation checked on 6 November 2026; version-specific caching options should be verified against the version you deploy.

I use modern AI tools to help make my technical writing easier to read.

Give your helpdesk a diagnostic check, not SSH access

lastmileops — Tue, 03 Nov 2026 14:45:29 +0000

A Linux example using Bash and jq; the code was checked locally.

"Could you check whether the VPN hostname resolves?" It's a simple question with a ten-second answer. But if you have to
track down the on-call network engineer first, those ten seconds can easily turn into a separate ticket and a wait.

The helpdesk can answer questions like this on its own. What it needs is a check with clear boundaries.

Shell access doesn't automatically make someone an administrator: that depends on the account's permissions. But even
an unprivileged shell lets its user run commands, read accessible files and connect to accessible services. For a question
like "does this host respond?", that's usually more access than the job needs.

You can start with a small diagnostic script and three rules:

Only known targets. The network team maintains the host list; neither the helpdesk nor the process running the check can change it.
Only named checks. The user chooses dns, port443 or ping.
Validate the input before running the check. Return the result, including the reason for a refusal, in a clear format.

The allowed hostnames go in /etc/diag/hosts.allow, one per line:

vpn.internal
intranet.internal

Here's the script:

#!/bin/bash
# diag.sh HOST CHECK — only allowed hosts and checks.
set -uo pipefail
export PATH=/usr/bin:/bin LC_ALL=C
readonly ALLOWLIST=/etc/diag/hosts.allow
host="${1:-}"; check="${2:-}"
emit() {
  jq -nc --arg host "$host" --arg check "$check" \
    --arg result "$1" --arg reason "${2:-}" \
    '{host:$host, check:$check, result:$result}
     + (if $reason == "" then {} else {reason:$reason} end)'
}
fail() { emit refused "$1"; exit 2; }
[[ $# -eq 2 ]] || fail "expected HOST CHECK"
[[ "$host" =~ ^[A-Za-z0-9][A-Za-z0-9.-]{0,252}$ ]] || fail "invalid host name"
[[ -r "$ALLOWLIST" ]] || { emit error "allowlist is unavailable"; exit 1; }
grep -qxF -- "$host" "$ALLOWLIST" || fail "host is not on the allowlist"
case "$check" in
  dns)
    out=$(timeout 5 getent hosts "$host") || {
      emit error "name lookup failed or timed out"; exit 1;
    }
    out=$(printf '%s\n' "$out" | awk '{print $1}' | paste -sd, -) || {
      emit error "name lookup output could not be formatted"; exit 1;
    }
    ;;
  port443)
    out=$(timeout 5 bash -c 'exec 3<>"/dev/tcp/$1/443"' diag "$host" \
      2>/dev/null && echo open || echo no_connection)
    ;;
  ping)
    out=$(timeout 5 ping -c1 -W2 "$host" >/dev/null 2>&1 \
      && echo reachable || echo no_reply)
    ;;
  *) fail "unknown check (use dns, port443 or ping)" ;;
esac
emit "${out:-none}"

The allowlist path is fixed in the script: DIAG_ALLOWLIST cannot be used to substitute another file. The script, the list
and their parent directories must be protected against writes by both the helpdesk and the account that runs the check.
A fixed path is no help if the caller can replace the file at that path.

Here's what the helpdesk gets back:

{"host":"vpn.internal","check":"dns","result":"10.0.4.12"}
{"host":"vpn.internal","check":"port443","result":"open"}
{"host":"vpn.internal;reboot","check":"dns","result":"refused","reason":"invalid host name"}
{"host":"db-prod","check":"dns","result":"refused","reason":"host is not on the allowlist"}

An attempt to append ;reboot stops at the character check. A name starting with - is rejected too, and -- tells
grep where command options end and the name begins. The script refuses db-prod because that host isn't on the list.

Read the results literally. Here, dns checks the system's name resolution, including /etc/hosts.
open means a TCP connection to port 443 was established; it doesn't prove that TLS or the application itself is healthy.
no_connection and no_reply mean no response was obtained under the conditions of the check. There can be several reasons for that.

Now for the important part: how do you use this without SSH?

An existing internal form or company bot needs just two fields: "Host" and "Check". The employee signs in through the
company's usual mechanism, and the handler verifies that they are allowed to run diagnostics. Dropdowns make things
convenient for the user; the server still needs to validate the arguments.

The handler runs the script as a separate, unprivileged account on a machine that can reach the required hosts. That
account cannot change the script, the target list or service settings. The employee gets no shell access to the machine.
The command and its path are set on the server; the user supplies only the two values.

For example, after checking access, the Python call looks like this:

import subprocess

completed = subprocess.run(
    ["/opt/diag/diag.sh", host, check],
    shell=False,
    stdin=subprocess.DEVNULL,
    capture_output=True,
    text=True,
    timeout=8,
    cwd="/",
    env={"PATH": "/usr/bin:/bin", "LC_ALL": "C"},
)

The arguments are passed as a list, without building a shell command from the request text. The standard
subprocess.run supports this directly.
The server also supplies the environment: the user doesn't choose the program path, the host list or Bash settings.

The handler returns the script's JSON to the employee and reports a launch error or timeout separately. The log records
the user, target, check and result. The form or bot provides authorization and logging; the script itself doesn't implement them.

That makes for a short path: choose vpn.internal → click "Check DNS" → get an answer you can attach to a ticket.
Restarting a service remains a separate action with separate permissions. It doesn't accidentally end up inside the diagnostics button.

Whenever I get the chance to make my geeky thoughts more pleasant for a wider audience, I don't shy away from what modern AI can do.

Your certificate renewed. Does your service know?

lastmileops — Tue, 27 Oct 2026 13:04:27 +0000

Tested with OpenSSL 3.6 and GNU date.

Automatic certificate renewal was invented to make expiry a non-event. Most of the time it is. But when something does break,
it breaks quietly and with imagination:

the DNS provider's API token expired, and domain validation no longer passes;
a new firewall politely drops the HTTP challenge, and nobody knows;
the deploy hook restarts a service that was renamed six months ago;
renewal went perfectly, and the service keeps serving the old certificate from memory.

And if you were counting on reminder emails from your CA: Let's Encrypt stopped sending them back in 2025. Nobody is going to
remind you now except you.

One simple idea covers that whole list: a check that doesn't trust the renewal job at all. It connects to the service the way
an ordinary client does and looks at the certificate that actually comes back. Not the file on disk, not the certbot log, but what
your users' browsers see.

#!/usr/bin/env bash
# check-cert.sh HOST[:PORT] [MIN_DAYS] — check the certificate a service actually presents
set -uo pipefail
target="$1"; min="${2:-14}"
host="${target%%:*}"; [[ "$target" == *:* ]] || target="$target:443"
pem=$(echo | timeout 10 openssl s_client -servername "$host" -connect "$target" 2>/dev/null \
      | openssl x509 2>/dev/null) || true
if [[ -z "$pem" ]]; then echo "UNREACHABLE: $target presented no certificate"; exit 2; fi
end=$(openssl x509 -noout -enddate <<<"$pem" | cut -d= -f2)
days=$(( ( $(date -u -d "$end" +%s) - $(date -u +%s) ) / 86400 ))
if ! openssl x509 -noout -checkhost "$host" <<<"$pem" | grep -q "does match"; then
  echo "MISMATCH: $target presents a certificate not valid for $host (expires in $days days)"; exit 2
fi
if (( days < 0 )); then echo "EXPIRED: $target expired on $end"; exit 1; fi
if (( days < min )); then echo "EXPIRING: $target expires in $days days ($end)"; exit 1; fi
echo "OK: $target valid for $days more days"

What it says:

OK: intranet.example.com:443 valid for 54 more days
EXPIRING: wiki.example.com:443 expires in 9 days (Nov  2 18:13:52 2026 GMT)
EXPIRED: old-vpn.example.com:443 expired on Feb  1 00:00:00 2025 GMT
MISMATCH: files.example.com:443 presents a certificate not valid for files.example.com (expires in 399 days)
UNREACHABLE: mail.example.com:465 presented no certificate

Pick a threshold below the point where renewal should already have happened. From February 10, 2027, Let's Encrypt will issue
64-day certificates by default, and it already recommends renewing at about two-thirds of the lifetime, which leaves roughly
21 days. An alert at 14 days stays quiet on normal renewals and fires when one is a week late. A 21-day threshold would page
someone on every routine renewal, and within a month everyone learns to ignore it. Which is exactly what we were trying to avoid.

MISMATCH is the sneakiest one. A virtual host lost its own certificate and quietly serves the server's default one. Technically
there is a certificate, and it's valid. Just not for this name. Your users' browsers will disagree with you.

Run it for every name and port that matters, and from a different machine than the one doing the renewals. Otherwise the
check and the renewal break together and stay silent together.

#!/usr/bin/env bash
# check-all.sh — run check-cert.sh for every host:port in certs.txt, print only problems
while read -r t _; do
  [[ -z "$t" || "$t" == \#* ]] && continue
  /opt/tools/check-cert.sh "$t" 14 || true
done < /opt/tools/certs.txt | grep -v '^OK'

0 7 * * * out=$(/opt/tools/check-all.sh); [ -z "$out" ] || echo "$out" | notify-oncall

Send the result to a role or a shared queue, not to whoever set all this up once. The address that gets the alert should outlive
the person who typed it in. Otherwise you end up like one thread on Spiceworks: renewal failed, and the notifications were going
to the mailbox of a former contractor who was long gone.

What it doesn't do. It doesn't validate the chain or revocation: if you need that, add -verify_return_error and your own CA
bundle to s_client. Services that upgrade with STARTTLS (SMTP on 25 and 587, IMAP on 143) need -starttls smtp or
-starttls imap. And it tells you that something broke, not why. For the why, keep a record of every renewal run: which
version, when, and how it ended.

Whenever I get the chance to make my geeky thoughts more pleasant for a wider audience, I don't shy away from what modern AI can do.

Run records and missed-run checks for scheduled scripts

lastmileops — Fri, 23 Oct 2026 17:29:50 +0000

Tested on Linux with bash, jq and GNU date.

A quiet Slack channel can mean two things: nothing went wrong, or the job never ran. Most small scheduled scripts can't
tell those apart, because the only trace they leave is the alert they send when something looks bad.

Two small additions fix that: write a record for every run, including the boring successful ones, and check separately
that each job actually finished recently.

1. One line per run

#!/usr/bin/env bash
# run-logged.sh JOB_NAME COMMAND... — run a job and append one JSON line per run to $RUN_LOG
set -uo pipefail
job="$1"; shift
log="${RUN_LOG:-/var/log/run-records.jsonl}"
rev=$(sha256sum "$(command -v "$1")" 2>/dev/null | cut -c1-12)
start=$(date -u +%FT%TZ)
out=$("$@" 2>&1); status=$?
end=$(date -u +%FT%TZ)
jq -nc --arg job "$job" --arg rev "${rev:-unknown}" --arg start "$start" --arg end "$end" \
      --argjson status "$status" --arg out "$(printf "%s" "$out" | tail -c 2000)" \
      '{job:$job, rev:$rev, start:$start, end:$end, status:$status, output:$out}' >> "$log"
exit "$status"

Use it in cron instead of calling the script directly:

0 6 * * * RUN_LOG=/var/log/run-records.jsonl /opt/tools/run-logged.sh nightly-report /opt/tools/nightly-report.sh

Every run now leaves a line with the job name, a short hash of the program that ran, start and end time, exit status and
the tail of its output — whether it found something or not. When someone asks "did it run on Tuesday, and which version?",
the answer is one jq away.

2. A separate check for missed runs

#!/usr/bin/env bash
# check-missed.sh JOB_NAME MAX_AGE_MINUTES — fail if the job has no finished, successful run recently
set -uo pipefail
job="$1"; max="$2"; log="${RUN_LOG:-/var/log/run-records.jsonl}"
last=$(jq -r --arg job "$job" 'select(.job==$job and .status==0) | .end' "$log" 2>/dev/null | tail -1)
if [[ -z "$last" ]]; then echo "MISSED: $job has no successful run on record"; exit 2; fi
age=$(( ( $(date -u +%s) - $(date -u -d "$last" +%s) ) / 60 ))
if (( age > max )); then echo "MISSED: $job last succeeded ${age} min ago (limit ${max})"; exit 2; fi
echo "OK: $job succeeded ${age} min ago"

Schedule it after the job's deadline and send its output wherever alerts go:

30 7 * * * RUN_LOG=/var/log/run-records.jsonl /opt/tools/check-missed.sh nightly-report 120 || notify-oncall

It complains in three cases: the job never succeeded, it last succeeded too long ago, or it keeps failing. A failed data
fetch shows up as a failed check instead of a clean report.

What this doesn't do

It doesn't make the script correct, and it doesn't tell you why a run was skipped — only that it was. It's also still a
file on one machine: if several people depend on the job, they need somewhere to see these records that isn't your shell.

This article was created with the help of AI. The code was run on Linux before publishing.