ogrechkoandClaude Sonnet 5
b8ca595d34
Bisecting through attribute selection and paging kept reproducing the
same failure in different shapes ("Encoding too long" BER parser error,
then ECONNRESET) — all while a plain `ldapsearch` against the exact same
query, run from inside this same container, completed successfully every
single time. That's strong enough evidence of a bug somewhere in
ldapjs/@ldapjs-asn1's BER decoding against this AD's actual response
bytes, not in our query. Rather than keep chasing a third-party parser
bug, searchLdapDirectory() now shells out to the system `ldapsearch`
(added to the image via ldap-utils) and parses its LDIF output directly
— the same tool that's already proven reliable here. authenticateLdapUser
(the per-login lookup) is untouched: it's a narrow single-match query
that has shown no sign of this issue, and isn't worth the added latency
of spawning a process on every login.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_012o9j9RezxbZVKQMrB7oRLY
33 lines
1.4 KiB
Docker
33 lines
1.4 KiB
Docker
FROM node:20-bookworm-slim
|
|
|
|
# python3/make/g++ let npm fall back to compiling better-sqlite3/argon2 from
|
|
# source if no prebuilt binary matches this platform. ldap-utils provides
|
|
# the `ldapsearch` binary used for the LDAP directory browse — ldapjs's own
|
|
# BER decoder proved unreliable against real AD responses for that query.
|
|
RUN apt-get update && apt-get install -y --no-install-recommends \
|
|
python3 make g++ ca-certificates ldap-utils \
|
|
&& rm -rf /var/lib/apt/lists/*
|
|
|
|
WORKDIR /app
|
|
|
|
COPY package.json package-lock.json ./
|
|
RUN npm ci
|
|
|
|
COPY . .
|
|
# `next build`'s page-data collection spins up several parallel workers that
|
|
# each import the db client at module-eval time. If data/db.sqlite doesn't
|
|
# exist yet, every worker races to create it from scratch — that race is at
|
|
# the file-creation level, before our code ever gets to run a busy_timeout
|
|
# pragma, so it can throw SQLITE_BUSY (or worse) independent of pragma order.
|
|
# Migrating first — as its own isolated, single-process step — means the
|
|
# workers only ever see an already-existing, already-stable file.
|
|
RUN mkdir -p data && npm run db:migrate
|
|
RUN npm run build
|
|
|
|
ENV NODE_ENV=production
|
|
EXPOSE 8081
|
|
|
|
# Migrate the (volume-mounted) SQLite DB and bootstrap the admin account on
|
|
# every start — both are no-ops once already applied.
|
|
CMD ["sh", "-c", "npm run db:migrate && npm run bootstrap-admin && npm start"]
|