Security improvements

1. Add 'use mcp server' permission and access checks

• Added new permission use mcp server for basic MCP access
• Updated routing to require this permission for the /mcp/post endpoint
• Implemented hasAccess() checks in plugin base class with support for administrative override
• Added permission validation in JSON-RPC methods (ResourcesRead, ToolsCall)

2. Token authentication user selection

• Added user selection field in authentication settings form
• Token authentication can now be configured to use any user account
• Updated McpAuthProvider to load the configured user instead of hardcoded user 1
• Added validation to ensure configured user exists and is active
• Improved flood protection to use correct user ID

3. Content plugin opt-in behavior

• Changed default behavior to opt-in (all content types disabled by default)
• Updated form to clearly indicate opt-in behavior with description
• Modified isContentTypeEnabled() to return FALSE by default
• Added test updates to reflect new behavior

4. DrushCaller security improvements

• Implemented command allowlist system with categorization by risk level:
• Safe commands (read-only, enabled by default)
• Moderate risk (cache operations, disabled by default)
• Dangerous commands (database/file modifications, disabled by default with warnings)
• Added form-based configuration for granular command control
• Implemented strict mode for exact command matching
• Added ability to configure custom commands
• Command validation in both getTools() and executeTool() methods
• Clear security warnings in UI for dangerous commands

@gagosha
✅ 1. I see the permission.
✅ 2. I see user selection in token authentication.
✅ 3. Content types are disallowed by default.
❓4. Regarding drush - I don't see the granular form described, but the textarea. Is it how its intended to be used?

@jibla, just update the above comment for DrushCaller. Since the allowlist categorization doesn’t seem so stable, I decided to make it a text area where the user can opt-in to allowed commands or use the * wildcard.

When I encountered 🐛 Tool names easily exceed Claude Code's 64-character limit due to MD5 hash appending Active I stumbled upon the md5 implementation of tool ids. It's documented that:

When the MCP module exposes tools to clients, it prefixes the tool name with the plugin ID and uses MD5 hash for security. In your executeTool() method, compare the incoming ID with the MD5 hash of your tool name.

The claim is that this prevents someone from calling arbitrary tools by:
1. Only accepting valid hashes - If you don't know the original tool name, you can't generate the correct MD5
2. Preventing direct tool name guessing - An attacker can't just guess the original tool name

But:

1. The original names are exposed anyway!
description: "Original name: $tool->name, Description: $tool->description",
2. The tools/list response literally tells you: "Original name: organization_tree.create"
3. No real threat model - What attack does this prevent? If someone has access to call MCP tools, they already have
legitimate access?

But maybe I'm missing something?

Hey @askibinski, you’re not missing anything and you are right.

We need to change that part in the documentation. Thanks for mentioning it. The MD5 conversion is not part of the security in any case, and originally I wanted the tool names to stay original, but I couldn’t because of limitations with some clients.

Automatically closed - issue fixed for 2 weeks with no activity.