add TeamsLite demo for chat sdk

[xingsy97]

No description provided.

In general, the problem should be fixed by replacing the ad hoc regex-based HTML stripping with a well-tested sanitization strategy that correctly handles all HTML/script tag edge cases. For a React frontend, the safest approach is to sanitize incoming HTML and then extract plain text in a way that does not rely on fragile multi-character regexes.

The single best way to fix this, without changing visible functionality, is to parse the message content as HTML using the browser’s DOM parser, extract its plain text, and then normalize whitespace. This removes all tags and their attributes, regardless of how they are nested or split, and avoids the multi-character-sanitization problem completely. Specifically, in formatMessagePreview, replace:

const rawContent = lastMessage.content;
const content = rawContent.replace(/<[^>]*>/g, '').replace(/&nbsp;/g, ' ').trim();

with a helper that converts HTML to text via DOMParser (or a fallback <div> element) and then trims and normalizes spaces. This change happens entirely within Sidebar.tsx, does not require new dependencies, and preserves the rest of the logic (length limiting, private vs group handling).

Concretely:

• Add a small helper function stripHtmlTags (or htmlToText) inside Sidebar.tsx that:
  • Accepts a string.
  • Uses DOMParser (if available) to parse HTML and return textContent.
  • Falls back to creating a <div>, setting innerHTML, and reading textContent if DOMParser is unavailable.
  • Replaces non‑breaking spaces (\u00A0) with normal spaces and trims.
• Call this helper from formatMessagePreview instead of using the regex .replace(/<[^>]*>/g, '').

No new imports are required because both DOMParser and document.createElement are standard browser APIs in this client-side code.

---

In general, to fix externally-controlled format string issues with console.log/util.format, don’t let untrusted data participate in the format string. Instead, use a constant format string (with %s placeholders if needed) and pass untrusted values as separate arguments, or pre-concatenate them into a single string that is then logged alone.

For this specific case in sdk/webpubsub-chat-sdk/examples/teams-lite/server/index.js, line 53 currently builds a template literal containing userId and then passes err.message as a second argument:

console.log(`Self-chat room for ${userId} may already exist:`, err.message);

We can make the format string constant and pass userId and err.message as arguments to that format string. This preserves the log content while eliminating the untrusted format string. A good, minimal change is:

console.log('Self-chat room for %s may already exist: %s', userId, err.message);

No new imports or helpers are required; we only change the single console.log call in the catch block around chatClient.createRoom (around lines 51–54). Functionality remains the same: the log still reports the userId and the error message, but any % characters inside userId or err.message are treated as data, not format specifiers.

In general, to fix insecure randomness you must replace Math.random() with a cryptographically secure source such as crypto.randomBytes in Node.js or crypto.getRandomValues in the browser, and then derive your needed values from that secure source.

Here, the best fix is to change the implementation of randomInt so it no longer uses Math.random() and instead uses Node’s crypto module. We keep the same API (randomInt(): number) and roughly the same output range so existing behavior (tests creating user IDs like uid-<big number>) is preserved except for stronger randomness. A straightforward, bias‑free approach is to use crypto.randomInt(0, 10000000). If we want to avoid relying on newer Node APIs, we can instead use crypto.randomBytes and map bytes into the requested range; however, crypto.randomInt is part of Node’s standard library and avoids manual bias concerns.

Concretely:

• Add an import for randomInt (renamed to avoid collision) from Node’s crypto module.
• Rewrite the local randomInt helper to call cryptoRandomInt(0, 10000000) instead of Math.random() * 10000000.
• No other lines need to change because all usages (getUserIds, createTestClient) will automatically use the stronger randomness.

All changes are within sdk/webpubsub-chat-sdk/tests/testUtils.ts:

• Add import { randomInt as cryptoRandomInt } from "crypto"; near the top.
• Change the definition of randomInt on line 10 to use cryptoRandomInt.

To fix the problem in general, add a rate-limiting middleware to the Express application and apply it to the route (or routes) that perform file-system access or other expensive operations. A commonly used solution in the Node/Express ecosystem is the express-rate-limit package, which allows you to define a window and a maximum number of requests per IP within that window. The middleware should be applied before the app.get('{*path}', ...) handler so that excessive requests are blocked or slowed before reaching res.sendFile.

In this specific file, the minimal-impact fix is:

• Import express-rate-limit at the top (without touching existing imports).
• Define a rate limiter instance, e.g., fileAccessLimiter, configured with a reasonable window and max requests.
• Apply that limiter specifically to the app.get('{*path}', ...) route (or also to express.static if desired), so that requests for the static index page are constrained. This preserves existing behavior for legitimate users while mitigating abuse.
• Keep all existing logic inside the route intact; only prepend the limiter as middleware.

Concretely:

• In sdk/webpubsub-chat-sdk/examples/teams-lite/server/index.js, add an import for express-rate-limit alongside the existing imports.
• After creating const app = express(); (or near other configuration constants), define const fileAccessLimiter = rateLimit({...}).
• Change app.get('{*path}', (req, res, next) => { ... }) to app.get('{*path}', fileAccessLimiter, (req, res, next) => { ... }).