Repository navigation
fix: resolve the identity field and prefer webware's user contract - #100
Merged
Merged
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
webware-tools moves from 1.0.0-rc.5 to 1.0.0-rc.6, which takes the mago pin from 1.55.0 to 1.57.0. webware-core joins require-dev so the middleware can name its user contract through ::class. It stays a dev requirement: a consumer that uses no other webware component never installs it, and the constant resolves to the attribute key without the interface being loaded.
Reformats the files mago 1.57.0 lays out differently from 1.55.0: a chain whose receiver is a variable now starts on the receiver's own line. Whitespace only, verified by comparing each file against HEAD with all whitespace stripped.
MonologMiddleware looked the authenticated user up under one hardcoded attribute, mezzio's contract, while IdentityMiddleware attaches the user under Webware\Core\UserInterface. Two different class names never match, so every log row this package has written carries a NULL user_identifier. The lookup now tries webware's contract first and mezzio's second, both as attribute keys, so a host on either contract is enriched and a request carrying both resolves to webware's. The processor also wrote the identity to a fixed extra['email'], while PhpDbHandlerFactory read authentication.username - defaulting to 'email' - to decide which extra key to strip into the user_identifier column. Setting authentication.username to anything else made the producer and the consumer disagree, leaving the column NULL and leaking the identity into the serialized context instead. Both sides now resolve that name through a new IdentityField class, so renaming the identity column moves both at once. The auth_attribute config key is removed: it could only ever hold one of the two contract names, and a host maps its implementation onto one of those contracts, so the name is not the host's to choose. A configuration still setting it is unaffected - the key is simply ignored.
tyrsson
force-pushed
the
fix/monolog-identity-enrichment
branch
from
October 15, 2026 17:01
8a82c1a to
09fa7a9
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this fixes
Two defects that made
user_identifierNULL on every row this package has ever written.1. The attribute key never matched.
MonologMiddlewarelooked the authenticated user up underMezzio\Authentication\UserInterface.IdentityMiddlewareattaches the user underWebware\Core\UserInterface. Request attributes are keyed by class name, so the lookup missed every time, the processor was never pushed, andextranever carried an identity forPhpDbHandlerto strip into the column. Verified against the running app: attaching the identity under webware's key producesuser_identifier = 'jsmith@webinertia.net'; under mezzio's key the column stays NULL.The lookup now tries webware's contract first and mezzio's second, both as attribute keys, so a host on either contract is enriched and a request carrying both resolves to webware's.
2. The producer and the consumer disagreed about the extra key. The processor wrote
extra['email']unconditionally, whilePhpDbHandlerFactoryreadauthentication.username(defaultemail) to decide which key to strip. Pointauthentication.usernameat a non-email identity column and the two fall apart: the column goes NULL and the identity leaks into the serializedcontextinstead. Both sides now resolve the name through a newIdentityFieldclass, so renaming the column moves both.auth_attributeis removedThe key could only ever hold one of the two contract names, and a host maps its implementation onto one of those contracts, so the name is not the host's to choose. A configuration still setting it is unaffected: the key is ignored, and the fixed lookup is strictly better than what it replaced.
Dependency change
webware/webware-corejoinsrequire-dev, alongside thewebware-toolsbump to1.0.0-rc.6that takes the mago pin from 1.55.0 to 1.57.0.It is a dev requirement on purpose. The middleware names webware's contract as one of the two attribute keys it reads, and it cannot be written as a string literal: naming an absent class is an analyze error, and the literal trips
no-literal-namespace-string, whose centre config fails the gate atHelplevel. Requiring it as a dev dependency is the same shape this package already uses for Mezzio's contract, whichsrc/ConfigProvider.phpreferences through::classwhilemezzio/mezzio-authenticationsits inrequire-dev. A consumer that uses no other webware component still installs none of it.Net effect on this package's dev install: 6 packages, all laminas and psr, no conflicts.
Verification
IdentityFieldcases and the contract-preference cases).mago format --check,lint,analyzeandguardall exit 0 against the 1.57.0 config, with no new findings.webwareapp against MySQL and Mailpit: an admin-created user accepts the set-password link and the first sign-in writes onesecurityrow.Commits
chore(deps): bump webware-tools to 1.0.0-rc.6 and add webware-corechore: apply mago 1.57.0 formatting- 10 files, whitespace only, proven by comparing each against HEAD with all whitespace stripped.fix: resolve the identity field and prefer webware's user contract- the change itself, its tests, the docs, and the regenerated analysis baseline.Note for review
analysis-baseline.tomlis regenerated. Droppingauth_attributefrom the inferredLogDefaultsshape rewrote the message text of six baselined entries, which orphaned them and made the same findings reappear as new. The regenerated file suppresses the same findings; the entry count moves from 22 to 20 because two message variants collapsed.Three test fixtures in
LogFactoryTest,MezzioErrorHandlerDelegatorTestandPhpDbHandlerFactoryTesthad the now-deadauth_attributekey removed alongside their reformatting.A correction to an earlier revision of this description: I first claimed lint warnings do not fail the gate. They do. The centre sets
[linter] minimum-fail-level = "Help", and my measurement had read a stale exit code. The dev requirement above is the consequence.