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 |
||
|---|---|---|
| .. | ||
| rag_pipeline | ||
| data_source.py | ||
| datasets_document.py | ||
| datasets_segments.py | ||
| datasets.py | ||
| error.py | ||
| external.py | ||
| hit_testing_base.py | ||
| hit_testing.py | ||
| metadata.py | ||
| website.py | ||
| wraps.py | ||