Skip to content

Added cleared:true to allow the MCP server to pull cleared alerts#79

Open
unifiedjd wants to merge 9 commits intomonitoringartist:mainfrom
r2utgit:main
Open

Added cleared:true to allow the MCP server to pull cleared alerts#79
unifiedjd wants to merge 9 commits intomonitoringartist:mainfrom
r2utgit:main

Conversation

@unifiedjd
Copy link
Copy Markdown

Description

Simple change to allow the MCP server to pull cleared alerts.

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Documentation update
  • Performance improvement
  • Code refactoring
  • Test improvements
  • CI/CD changes

Changes Made

Testing

Tested with Claude direct to MCP server.

  • All existing tests pass
  • New tests added for new functionality
  • Manual testing performed
  • E2E tests pass

Test Configuration:

  • Node version:
  • OS:

Checklist

  • My code follows the project's code style
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation
  • My changes generate no new warnings or errors
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • Any dependent changes have been merged and published

Additional Notes

unifiedjd and others added 9 commits March 21, 2026 20:59
…loys (#1)

Register Passport strategies under their provider name so passport.authenticate('azure'|'google'|'okta'|'auth0'|'custom') resolves correctly; previously the OAuth2Strategy registered under its default name 'oauth2', causing "Unknown authentication strategy" 500s at /auth/login.

Also honor the EXPRESS_TRUST_PROXY env var so Azure Container Apps (and other reverse proxies) don't trigger express-rate-limit X-Forwarded-For validation errors.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* Fix OAuth strategy registration and trust proxy for reverse-proxy deploys

Register Passport strategies under their provider name so passport.authenticate('azure'|'google'|'okta'|'auth0'|'custom') resolves correctly; previously the OAuth2Strategy registered under its default name 'oauth2', causing "Unknown authentication strategy" 500s at /auth/login.

Also honor the EXPRESS_TRUST_PROXY env var so Azure Container Apps (and other reverse proxies) don't trigger express-rate-limit X-Forwarded-For validation errors.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* Add OAuth 2.1 Authorization Server endpoints for MCP clients

Implements the AS surface that OAuth 2.1 MCP clients (Claude's remote
connector, etc.) need to authenticate end-users through the configured
IdP (Microsoft Entra) and receive a server-minted JWT.

New routes:
  GET  /.well-known/oauth-protected-resource   (RFC 9728)
  GET  /.well-known/oauth-authorization-server (RFC 8414)
  POST /oauth/register                         (RFC 7591 DCR, public client)
  GET  /oauth/authorize                        (auth code + PKCE, S256)
  POST /oauth/token                            (code -> JWT exchange)

Flow: client probes /mcp -> 401 advertises /.well-known/... -> discovers
AS metadata -> registers via /oauth/register -> redirects user to
/oauth/authorize (we stash the pending authz in the browser session) ->
federates to the IdP via the existing passport strategy -> /auth/callback
detects pending authz, mints an auth code, redirects to the client's
redirect_uri -> client posts code + PKCE verifier to /oauth/token ->
server verifies PKCE and mints a JWT via jwtValidator.createToken().

The JWT carries the user's identity and a baseline scope set that covers
all mapped tools. A TODO(option-3) marks the seam where this fixed scope
will be replaced by a mapping derived from the authenticated user's
Entra group memberships in a follow-up change. LM's own RBAC still
applies via the shared LM_BEARER_TOKEN.

Storage for registered clients, pending authorizations, and
authorization codes is in-memory with TTL cleanup; a single-replica
deployment is fine but multi-replica needs Redis.

CSRF middleware already skipped /.well-known/*; extended to /oauth/*.
Added express.urlencoded() for the /oauth/token form body per RFC 6749.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
/oauth/authorize stashed the pending authorization in req.session, but
Passport >= 0.6 regenerates the session on successful req.login() as a
session-fixation defence. That wipes any data set before the IdP round-
trip, so by the time /auth/callback runs, session.pendingAuth is gone
and the callback falls through to the legacy "redirect to /" branch —
Claude's connector is left waiting indefinitely for a code that never
arrives at its redirect_uri.

Move pendingAuth out of req.session entirely:
- Add a server-side Map keyed by a random transactionId
  (storePendingAuthorization / consumePendingAuthorization)
- In /oauth/authorize, create the transactionId, store the authorization,
  and emit a dedicated HttpOnly SameSite=Lax cookie (mcp_oauth_tx) that
  Passport never touches.
- In /auth/callback, read the cookie, consume the pending authorization
  from the server-side store, clear the cookie, and (on success) mint
  the authorization code and redirect to the client's redirect_uri.
- Extend the periodic cleanup to expire stale pending authorizations.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
docker.yml was inherited from the upstream monitoringartist/
logicmonitor-mcp-server fork and was trying to publish images to that
repo's Docker Hub namespace (monitoringartist/logicmonitor-mcp-server),
which requires DOCKERHUB_USERNAME / DOCKERHUB_TOKEN secrets this fork
doesn't set. It has been failing on every push to main, generating
noise, while not contributing anything — this fork deploys via Azure
Container Apps' own auto-deploy workflow, which builds the container
itself.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant