Можно ли ограничить область действия API-ключа так, чтобы он мог выполнять операции чтения и записи для запросов в Data Explorer, не предоставляя при этом глобально scoped административный API-ключ?
Data explorer никогда не может ничего записать.
Вы можете создать запрос и разрешить членам группы, которые иначе не имеют доступа к плагину, запускать определенные запросы.
2 лайка
Извините, возможно, это было сформулировано не совсем ясно. Разве сами запросы нельзя создавать через API?
Речь идёт именно об этой функции — чтении и записи самих запросов, а не о данных внутри запроса.
Ой, извините. Я действительно упустил это. Значит, вы хотите создавать запросы через API, а не просто выполнять их. Это другое.
Подозреваю, что ответ — нет.
Какую проблему вы решаете, создавая запросы через API? Вам нужно создавать их в большом количестве или что-то в этом роде?
1 лайк
Вы можете создавать их через API. Мой вопрос: можем ли мы как-то ограничить область действия API-ключа для этого? В настоящее время область действия API-ключа можно ограничить только чтением запросов Data Explorer, но нет возможности ограничить её записью.
Поэтому сегодня, если я хочу предоставить кому-то в моей организации возможность писать запросы для Data Explorer, мне приходится выдавать им полный глобальный административный API-ключ.
Вот документация по созданию запросов через API:
А, понятно. Вы доверяете конкретному человеку написание запросов, но не больше ничего. Я не думаю, что в данный момент существует способ сделать это.
1 лайк
Похоже, то, о чём вы просите, — и что, как мне кажется, отличная идея, от которой выиграли бы многие сообщества, — это настройка вроде data_explorer_allowed_groups, позволяющая предоставить полный доступ к Data Explorer большему числу групп помимо администраторов.
Скорее всего, если группе разрешён доступ, то API-ключ этого пользователя будет работать как для создания запросов, так и для доступа к ним.
В настоящее время возможно только предоставить людям доступ к существующим запросам через их страницу группы.
Я переместил это обсуждение в канал #feature, чтобы запрос на новую функцию мог быть рассмотрен. Не уверен, что его подхватят, но хотя бы эта идея теперь озвучена.
Причина, по которой этого не стоит делать, заключается в том, что это даёт указанным лицам полный (хотя и только для чтения) доступ ко всему содержимому базы данных: паролям, IP-адресам (к которым обычно имеют доступ модераторы), всем секретам в SiteSettings и, вероятно, кое-каким другим данным. С другой стороны, доступ только для чтения, так что это не то же самое, что быть администратором. Кроме того, там содержатся секреты, необходимые для входа в систему от имени другого пользователя, если у вас есть ссылка для входа, отправленная на почту.
2 лайка