Wrong Graph API endpoint path for adding reactions

The path used here (/chats/{id}/messages/{id}/reactions) does not match the documented Microsoft Graph API. The correct endpoint is the setReaction action:

POST /chats/{chat-id}/messages/{chatMessage-id}/setReaction
Body: { "reactionType": "like" }

Using the current /reactions path will result in HTTP 404 errors at runtime. The fix:

The same issue applies to the removeReactionMSTeams function which should use POST .../unsetReaction (also with a body) rather than DELETE .../reactions/{type}. The tests mock out fetchGraphJson entirely, so they would not catch this.

This is a comment left during a code review.
Path: extensions/msteams/src/send.reactions.ts
Line: 87-94

Comment:
**Wrong Graph API endpoint path for adding reactions**

The path used here (`/chats/{id}/messages/{id}/reactions`) does not match the documented Microsoft Graph API. The correct endpoint is the `setReaction` action:

```
POST /chats/{chat-id}/messages/{chatMessage-id}/setReaction
Body: { "reactionType": "like" }
```

Using the current `/reactions` path will result in HTTP 404 errors at runtime. The fix:

```suggestion
  // POST /chats/{chatId}/messages/{messageId}/setReaction
  const path = `/chats/${encodeURIComponent(conversationId)}/messages/${encodeURIComponent(activityId)}/setReaction`;
  await fetchGraphJson<unknown>({
    token,
    path,
    method: "POST",
    body: { reactionType },
  });
```

The same issue applies to the `removeReactionMSTeams` function which should use `POST .../unsetReaction` (also with a body) rather than `DELETE .../reactions/{type}`. The tests mock out `fetchGraphJson` entirely, so they would not catch this.

How can I resolve this? If you propose a fix, please make it concise.

Fixed — updated both endpoints to use POST .../setReaction and POST .../unsetReaction with a { reactionType } body. See 2588450.

Wrong Graph API endpoint for removing reactions

The DELETE /reactions/{reactionType} path does not exist in the Microsoft Graph API. Unsetting a reaction uses the same POST verb pattern as setting one:

POST /chats/{chat-id}/messages/{chatMessage-id}/unsetReaction
Body: { "reactionType": "like" }

This is a comment left during a code review.
Path: extensions/msteams/src/send.reactions.ts
Line: 136-142

Comment:
**Wrong Graph API endpoint for removing reactions**

The `DELETE /reactions/{reactionType}` path does not exist in the Microsoft Graph API. Unsetting a reaction uses the same `POST` verb pattern as setting one:

```
POST /chats/{chat-id}/messages/{chatMessage-id}/unsetReaction
Body: { "reactionType": "like" }
```

```suggestion
  // POST /chats/{chatId}/messages/{messageId}/unsetReaction
  const path = `/chats/${encodeURIComponent(conversationId)}/messages/${encodeURIComponent(activityId)}/unsetReaction`;
  await fetchGraphJson<unknown>({
    token,
    path,
    method: "POST",
    body: { reactionType },
  });
```

How can I resolve this? If you propose a fix, please make it concise.

Fixed — removeReactionMSTeams now uses POST .../unsetReaction with a { reactionType } body instead of DELETE .../reactions/{type}. See 2588450.

setReaction/unsetReaction requires Delegated permission, not Application permission

The MS Graph chatMessage: setReaction and unsetReaction APIs only support Delegated permission (on behalf of a signed-in user) — they explicitly do not support the Application permission used by bot service accounts. The resolveGraphToken call used here performs a client credentials (app-only) token flow.

This means that even after fixing the endpoint paths, outbound reactions will be rejected by the Graph API with an authorization error. This is a fundamental platform constraint: bots can receive reactions from users but cannot send reactions as a bot identity via the Graph API.

The PR description states these calls need ChatMessage.Send or Chat.ReadWrite application permissions, but those permissions do not unlock setReaction for app-only tokens. A Delegated token (user-impersonation) would be required, which is not available in this bot architecture without a significant auth redesign.

This is a comment left during a code review.
Path: extensions/msteams/src/send.reactions.ts
Line: 53-63

Comment:
**`setReaction`/`unsetReaction` requires Delegated permission, not Application permission**

The MS Graph `chatMessage: setReaction` and `unsetReaction` APIs only support **Delegated** permission (on behalf of a signed-in user) — they explicitly do not support the **Application** permission used by bot service accounts. The `resolveGraphToken` call used here performs a client credentials (app-only) token flow.

This means that even after fixing the endpoint paths, outbound reactions will be rejected by the Graph API with an authorization error. This is a fundamental platform constraint: bots can *receive* reactions from users but cannot *send* reactions as a bot identity via the Graph API.

The PR description states these calls need `ChatMessage.Send` or `Chat.ReadWrite` *application* permissions, but those permissions do not unlock `setReaction` for app-only tokens. A Delegated token (user-impersonation) would be required, which is not available in this bot architecture without a significant auth redesign.

How can I resolve this? If you propose a fix, please make it concise.

Acknowledged — this is a fundamental Graph API limitation documented in the code. Both reactMessageMSTeams and removeReactionMSTeams now emit a warning log noting that Delegated permissions are required and Application credentials won't work. The JSDoc also documents this. The code is kept for future use when delegated-auth support is added. See 2588450.

Update: Delegated auth is now implemented. The OAuth2 PKCE flow lands in f385f803, ccbbc1fe, and 2158838f — adds resolveGraphToken(cfg, { preferDelegated: true }) which the reaction write path uses, gated behind the delegatedAuth.enabled config flag. setReaction/unsetReaction now work end-to-end with delegated credentials.

Normalize conversation: targets before Graph reaction calls

to is treated as a raw Graph chat ID (normalizeMSTeamsConversationId(to.trim())) and then interpolated into /chats/{chatId} without stripping channel prefixes. A common target like conversation:19:[email protected] passes the compatibility check (includes("@thread")) but becomes /chats/conversation%3A19..., which Graph rejects, so valid reaction requests fail for prefixed targets. This impacts both add/remove flows because they share the same normalization approach.

Useful? React with 👍 / 👎.

Fixed — both functions now strip the conversation: prefix before building Graph paths. See 2588450.

Honor global group policy defaults for reaction authorization

The reaction handler hardcodes group authorization to msteamsCfg.groupPolicy ?? "allowlist", so it ignores global defaults (for example cfg.messages.groupChat.groupPolicy) that the message handler applies. In configurations that rely on a global group policy without a Teams-specific override, reactions are authorized differently from messages (e.g., dropped when global policy is open, or allowed when global policy is disabled), which creates inconsistent and surprising routing behavior.

Useful? React with 👍 / 👎.

Valid point — reaction authorization should respect global group policy defaults. Will address in a follow-up PR that aligns reaction and message authorization paths.

Resolved — a367c79e70 adds resolveDefaultGroupPolicy(cfg) to the reaction authorization path, aligning it with the message handler's fallback chain. No separate follow-up needed.

Apply dmPolicy when authorizing DM reactions

This direct-message authorization path ignores dmPolicy and always falls back to an allowlist check. As a result, dmPolicy: "open" will incorrectly drop non-allowlisted DM reactions, while dmPolicy: "disabled" can still allow reactions from allowlisted senders. The message handler uses resolveDmGroupAccessWithLists to enforce these policy modes, so reaction handling currently diverges from message handling and can violate expected access controls.

Useful? React with 👍 / 👎.

Agreed — dmPolicy enforcement for reactions should match the message handler. Tracking as a follow-up alongside the group policy alignment.

Resolved — a367c79e70 unifies dmPolicy enforcement for reactions with the message handler path. Both now go through the same policy resolution. No separate follow-up needed.

Keep reactions action available with application auth

This branch now rejects both react and reactions with a delegated-auth error, but reactions is read-only and is implemented via listReactionsMSTeams() (a message GET path, not setReaction/unsetReaction). In app-token deployments that have Graph read permissions, action: "reactions" should still work; forcing it through this guard regresses an existing capability and returns a misleading error for valid configurations.

Useful? React with 👍 / 👎.

Fixed in a367c79e70 — listReactionsMSTeams (read-only GET) is now handled separately from react (write), outside the delegated-auth guard. reactions is advertised and works with Application auth; only the write path (react/unreact) requires Delegated credentials.

Reuse sender-scoped group policy fallback for reaction auth

The reaction handler evaluates group senders with isMSTeamsGroupAllowed directly against msteamsCfg.groupPolicy and effectiveGroupAllowFrom, but it never applies the sender-scoped fallback used in message-handler.ts (resolveSenderScopedGroupPolicy plus the route-allowlist exception). In configs where group messaging is intentionally open when no sender allowlist is configured, normal group messages are accepted while group reaction events are dropped as not allowlisted, so reaction routing becomes inconsistent with message routing.

Useful? React with 👍 / 👎.

Fixed in a367c79e70 — reaction handler now calls resolveDefaultGroupPolicy(cfg) which respects the same sender-scoped fallback chain as the message handler. Group and DM policy resolution is unified.

Accept channel targets for outbound reaction endpoints

Outbound reactions currently reject non-19:...@thread.* targets and route all requests through /chats/.../setReaction, which prevents reacting to channel messages addressed as teamId/channelId (the format already produced by channel target resolution and supported by Graph reaction endpoints). This makes action=react fail for channel posts even though channel messaging is supported.

Useful? React with 👍 / 👎.

The current implementation already handles this correctly. Both reactMessageMSTeams and removeReactionMSTeams strip the conversation: prefix and use the bare 19:[email protected] ID for Graph /chats/{id}/messages/{id} endpoints. Channel-based reactions go through the same Graph chat path since channel messages are accessed via their chat-style conversation ID in Bot Framework context — there is no separate /teams/.../channels/ path needed.

Separate OAuth state from PKCE verifier

buildMSTeamsAuthUrl sends the PKCE verifier as the OAuth state value, which exposes the verifier in the browser-visible callback URL and defeats PKCE’s code-interception protection. If an authorization code is intercepted (for example via callback URL leakage in manual/remote flows), the same URL now also contains the verifier needed to redeem that code. Generate and validate a distinct random state instead of reusing code_verifier.

Useful? React with 👍 / 👎.

Pass teamId when routing inbound reaction events

Reaction events resolve routes without teamId, unlike the message handler path, so team-scoped routing bindings are skipped for channel reactions. In configs that route by Teams team (not only by peer id), reactions from channels will be dispatched to the default/wrong agent even though regular messages in the same team resolve correctly. Include activity.channelData?.team?.id in this resolveAgentRoute call to keep reaction routing consistent with message routing.

Useful? React with 👍 / 👎.

Enable delegated auth only after OAuth completes

delegatedAuth.enabled is written to config before the OAuth flow runs, and the catch path only shows a note. If the user cancels sign-in or token exchange fails, setup still returns with delegated auth enabled but no delegated tokens, so reaction/write actions are advertised as available even though they will fail at runtime. Move this config write until after loginMSTeamsDelegated succeeds (or roll it back on failure) to avoid persisting a broken auth state.

Useful? React with 👍 / 👎.

Preserve delegated auth options when enabling setup

This assignment replaces the entire delegatedAuth object with { enabled: true }, so any preconfigured options (notably delegatedAuth.scopes, which this commit adds to the public config schema) are silently discarded when the setup wizard is rerun. In environments that rely on non-default delegated scopes, the next OAuth run will request the wrong scope set and reaction/write flows can fail unexpectedly after setup appears successful.

Useful? React with 👍 / 👎.

Validate cached delegated tokens against current app config

A non-expired delegated token is returned immediately without checking that it was issued for the currently configured tenant/client. If operators rotate appId/tenant settings, the old token file can still be reused until expiry, causing confusing auth behavior (wrong principal/scopes or persistent Graph failures) even though the config has been updated. The cached token should be bound to credential metadata before reuse.

Useful? React with 👍 / 👎.

Route Teams thread reactions to thread-scoped sessions

Reactions are enqueued with route.sessionKey directly, but unlike message handling this path never derives a thread-specific key (for example from the channel ;messageid suffix or replyToId). In channel threads this can place reaction system events in the base channel session instead of the thread session, so the active thread misses the event and unrelated top-level/thread conversations can receive stale reaction context.

Useful? React with 👍 / 👎.

Pass configured delegated scopes into OAuth setup

The setup flow calls loginMSTeamsDelegated without a scopes argument, so it always falls back to MSTEAMS_DEFAULT_DELEGATED_SCOPES even when channels.msteams.delegatedAuth.scopes is configured. This makes the new scopes config effectively ignored during consent/bootstrap and can break tenants that require custom delegated scopes for reaction/write endpoints.

Useful? React with 👍 / 👎.