b6f218e1e6
* Stop leaking message body via the Notifications API tag
showNotification was passing the rendered chat body as the Web Notifications
API tag option. On Chromium-based browsers (Chrome, Edge, Brave), the tag is
serialised into the notification-activation command line via the
--notification-launch-id argument, where endpoint detection tooling such as
CrowdStrike Falcon FDR, Microsoft Defender for Endpoint, and Sysmon Event ID 1
captures the full process-start command line and forwards it to the customer's
SIEM. That meant private message content (including incident-response messages,
credentials accidentally pasted into chat, and customer PII) was being copied
into telemetry pipelines that were never in scope to receive it.
Use the title - which already carries only the sender / channel context - as
the tag instead. As a side benefit this is closer to the spec-intended use of
tag: subsequent notifications from the same conversation now replace the prior
one rather than stacking.
Add a regression test covering the leak: the test pushes a body with a
plausible secret pattern (token=AKIA-...) and asserts the tag never echoes
any of it.
* Allow callers to pass an explicit notification tag
Threads channelId through dispatchNotification so per-conversation
notifications coalesce by a stable opaque id rather than the user-visible
title. The title remains as a safe fallback when callers do not supply a
tag, preserving the existing behaviour for the session-expired notification
emitted from login.tsx where no channel context exists.
* fix: explain desktop notification path
* Avoid title fallback for notification tags
* test: align notification action payload expectations
* test: align notification tag e2e expectation
---------
(cherry picked from commit 55e7429fc6)
Signed-off-by: Vishal Kumar Singh <[email protected]>
Co-authored-by: Vishal Kumar Singh <[email protected]>
Co-authored-by: Mattermost Build <[email protected]>
Mattermost Web App
This folder contains the client code for the Mattermost web app. It's broken up into multiple packages each of which either contains an area of the app (such as playbooks) or shared logic used across other packages (such as the packages located in the platform directory). For anyone who's used to working in the mattermost/mattermost-webapp repo, most of that is now located in channels.
npm Workspaces
To interact with a workspace using npm, such as to add a dependency or run a script, use the --workspace (or --workspaces) flag. This can be done when using built-in npm commands such as npm add or when running scripts. Those commands should be run from this directory.
# Add a dependency to a single package
npm add react --workspace=playbooks
# Build multiple packages
npm run build --workspace=platform/client --workspace=platform/components
# Test all workspaces
npm test --workspaces
# Clean all workspaces that have a clean script defined
npm run clean --workspaces --if-present
To install dependencies for a workspace, simply run npm install from this folder as you would do normally. Most packages' dependencies will be included in the root node_modules, and all packages' dependencies will appear in the package-lock.json. A node_modules will only be created inside a package if one of its dependencies conflicts with that of another package.
Useful Links
- Developer setup, now included with the Mattermost server developer setup
- Web app developer documentation
Dependency Changes
Any PR that modifies package.json or package-lock.json needs extra scrutiny:
- No duplicate libraries. Before adding a new dependency, check whether an existing one already covers the same use case. Multiple libraries for the same purpose (e.g., two different date pickers, or Bootstrap 3 and Bootstrap 4 simultaneously) create long-term upgrade pain.
- License check. New dependencies must not use GPL or similarly restrictive licenses. Dependencies with no license at all should also be flagged.
- Justify the addition. A new dependency should solve a real problem that existing code or dependencies don't already address. Push back on adding packages for trivial functionality.
- Version conflicts. Check whether the new dependency introduces conflicting peer dependency versions. Cascading version conflicts are expensive to untangle later and have historically blocked upgrades for months.