项目文件夹

文件

T

Asim Aslam 96280678ee Expose framework primitives via API gateway and MCP with auth control (#2925 )

* feat: expose framework primitives via API gateway and MCP

Add registry, store, and broker as both HTTP routes and MCP tools
so AI agents and HTTP clients can inspect and operate the framework.

API gateway (/micro/* namespace):
  GET  /micro/registry         List registered services
  GET  /micro/registry/{name}  Describe a service
  GET  /micro/store            List store keys
  GET  /micro/store/{key}      Read a record
  POST /micro/store/{key}      Write a record
  POST /micro/broker/{topic}   Publish a message

MCP gateway (micro_* tool prefix):
  micro_registry_list    List services
  micro_registry_get     Describe a service
  micro_store_list       List keys
  micro_store_read       Read a record
  micro_store_write      Write a record
  micro_broker_publish   Publish a message

Framework tools use a Handler field on the MCP Tool struct for
direct dispatch (no RPC). Service tools continue to use RPC.
Rate limiters and circuit breakers are applied to framework
tools the same as service tools.

* fix: make framework internals opt-in on API and MCP gateways

Framework primitives (registry, broker, store) are now only
exposed when explicitly enabled:

API gateway:  micro api --internal
MCP gateway:  Options{Internal: true}

Off by default — user services are always exposed, framework
internals require the flag. Banner output only shows framework
routes when enabled.

* fix: always expose framework internals, gate by auth in production

Revert the --internal flag approach. Framework primitives (registry,
broker, store) are now always exposed:

- micro api: /micro/* routes always available (dev tool)
- MCP gateway: micro_* tools always registered. When Auth is
  configured (production), they require micro:admin scope.
  Without Auth (dev), they're open — same as all other tools.

This follows the existing pattern: micro run/api = dev (open),
micro server = production (auth + scopes). Framework internals
follow the same security model as user services.

Remove the Internal option from MCP Options. Remove --internal
flag from micro api.

Note: scope persistence depends on the store backend. The default
in-memory store does not survive restarts. Use MICRO_STORE=file
for persistent scopes in production.

* fix: correct DefaultStore comment — it's file-backed, not memory

* fix(server): don't recreate deleted admin user on restart

When the default admin account is deleted via the dashboard, set
a marker key (auth/.admin-deleted) in the store. On startup, skip
admin creation if the marker exists. This prevents the default
admin/micro credentials from reappearing after restart when the
user has intentionally removed them.

* fix: improve agent playground first-run UX and fix doc 404s

Agent playground:
- Add setup hint in empty state explaining how to get started
  (click Settings, enter API key, type a prompt)
- Hide hint automatically when API key is already configured
- Add all 7 providers to dropdown (was only OpenAI + Anthropic)
- Include CLI fallback suggestion (micro chat)

Docs:
- Fix .md links to .html across all doc pages — Jekyll serves
  .html files, not .md. Fixes 404s including the micro run guide.

---------

Co-authored-by: Claude <noreply@anthropic.com>

2026-06-03 11:05:51 +01:00

1.9 KiB

原始文件 永久链接 Blame 文件历史

TLS Security Update - Important Information

What Changed

The TLS configuration in go-micro now includes a security deprecation warning.

Current Behavior (v5.x)

Default: TLS certificate verification is disabled for backward compatibility

This maintains existing behavior to avoid breaking production deployments
A deprecation warning is logged once per process startup

Why: Changing the default to secure would be a breaking change that could disrupt:

Production systems during routine upgrades
Distributed systems with mixed versions
Services using self-signed certificates

How to Enable Security (Recommended)

Option 1: Environment Variable

export MICRO_TLS_SECURE=true

Option 2: Use SecureConfig

import (
    "go-micro.dev/v5/broker"
    mls "go-micro.dev/v5/util/tls"
)

broker := broker.NewHttpBroker(
    broker.TLSConfig(mls.SecureConfig()),
)

Migration Timeline

v5.x (Current): Insecure by default, opt-in security via MICRO_TLS_SECURE=true
v6.x (Future): Secure by default (breaking change with major version bump)

Why This Approach?

This addresses the concerns raised about:

Major version requirements: No breaking change in v5, deferred to v6
Cross-host compatibility: All hosts use same default behavior
Production safety: Existing deployments continue working during upgrades
Migration path: Clear opt-in path with documentation

Documentation

See SECURITY_MIGRATION.md for detailed migration guide.

Security Recommendation

For production deployments:

Test with MICRO_TLS_SECURE=true in staging
Use proper CA-signed certificates
Consider service mesh (Istio, Linkerd) for automatic mTLS
Plan migration before v6 release

Questions?

Open an issue on GitHub or check the documentation at https://go-micro.dev/docs/

1.9 KiB 原始文件 永久链接 Blame 文件历史