User Log Bundle Laravel Package

Getting Started

This release is a security-hardening patch: password parameters are now obfuscated before being recorded or emitted. That changes the first thing you should verify after upgrading, but it does not change install steps.

Start by confirming which surfaces the package writes to (logs, stored request records, debug output) and inspect one real entry containing a password field. The quickest first use case is a request that includes password and password_confirmation — submit it through your app, then confirm the stored/logged payload shows a redacted value rather than the plaintext.

If the package publishes config, re-publish or diff it after upgrading so you pick up any new obfuscation defaults:

composer update <vendor>/<package>
php artisan vendor:publish --tag=<package>-config --force
php artisan config:clear

Look first at the package's config file for an obfuscation/redaction key list, then at the code path that serialises parameters. That is where the v1.0.1 behaviour lives.

Implementation Patterns

• Treat redaction as a default, not a guarantee. Wrap any custom capture/logging you layer on top of the package with your own sanitiser for fields the package may not know about (e.g. secret, token, api_key). Do not assume "password" is the only sensitive key.
• Centralise a redaction list. Define a single array of sensitive keys in config and reuse it for both the package's obfuscation and any custom logging. This keeps behaviour consistent as new endpoints are added.
• Test the boundary. Add a feature test that posts a form with a password and asserts the captured payload does not contain the plaintext value. This guards against regressions when config or middleware order changes.
• Middleware ordering matters. If you capture requests via middleware, place the capture after the request is fully parsed but ensure the sanitiser runs before anything is persisted or queued. Queued logging can otherwise serialise raw input before redaction.
• Use it in debugging workflows. When reproducing a bug locally with request logging enabled, the obfuscation lets you share captured payloads more safely — but still review before pasting into tickets.

Gotchas and Tips

• Config cache is the usual culprit. After upgrading, run php artisan config:clear (and config:cache in production). Stale cached config can mean old, non-redacting behaviour persists.
• Nested and JSON payloads. Password fields inside nested arrays or JSON request bodies may not be caught by a flat key match. Verify the package handles nested structures; if not, flatten or recursively sanitise before capture.
• Case sensitivity. Password, PASSWORD, and user_password may slip through a case-sensitive exact-match list. Check the matching strategy and extend it if needed.
• Queued jobs and async writers. Anything that serialises the request before the obfuscation step runs can leak plaintext into the queue payload or failed-job table. Sanitise at the earliest point.
• Don't rely on it for compliance alone. Obfuscation of parameters is a defence-in-depth measure, not a substitute for not logging sensitive data, encrypting storage, and restricting access to log files.
• Extension point: if the package exposes a redaction callback or a "sensitive keys" config array, use that rather than forking — it survives future upgrades and keeps your customisations visible.