mirror of
https://github.com/langgenius/dify.git
synced 2026-09-05 16:55:14 +08:00
79116d8c4b
Legacy knowledge bases (`datasets`) and KnowledgeFS spaces (`knowledge_fs_control_spaces`) live in different tables, so a dataset API key binding could only ever name a legacy dataset and the KnowledgeFS service API never consulted bindings at all: a key scoped to specific knowledge bases still reached every KnowledgeFS space in the workspace. - Bindings carry a `resource_type` (`dataset` | `knowledge_fs_space`) and a nullable `control_space_id` (migration 9a4e7d1c2b60, existing rows stay `dataset`), with a CHECK that exactly one id column matches the type. - `dataset_api_key_service` exposes the key scope by kind, validates and binds KnowledgeFS spaces (tenant-owned, not deleting/deleted), and cleans up keys scoped only to a space when its deletion is requested. The orphan-key cleanup is now NULL-safe so a space binding keeps a key alive. - Legacy dataset routes only honour `dataset` bindings; the KnowledgeFS authorization service only honours `knowledge_fs_space` bindings and raises a scope error that the service API maps to 403 (unknown keys stay 401). - Console key creation accepts `knowledge_space_ids`; list/create responses return them next to `dataset_ids`. - The web scope picker lists KnowledgeFS spaces alongside legacy datasets when KnowledgeFS is enabled and submits the ids by kind; the scope column counts both. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015zw5G5SX3HmVfnZof6YWAc |
||
|---|---|---|
| .. | ||
| ar-TN | ||
| de-DE | ||
| en-US | ||
| es-ES | ||
| fa-IR | ||
| fr-FR | ||
| hi-IN | ||
| id-ID | ||
| it-IT | ||
| ja-JP | ||
| ko-KR | ||
| lo-LA | ||
| nl-NL | ||
| pl-PL | ||
| pt-BR | ||
| ro-RO | ||
| ru-RU | ||
| sl-SI | ||
| th-TH | ||
| tr-TR | ||
| uk-UA | ||
| vi-VN | ||
| zh-Hans | ||
| zh-Hant | ||