Какие настройки ролей администратора нужно настроить, чтобы иметь возможность доступа к Google Classroom API для домена? - PullRequest
1 голос
/ 22 марта 2020

Мы пытаемся создать отдельную роль администратора, чтобы назначать пользователям возможность вызова API Google Classroom (домен). Если мы установим их как «супер-администратор», это будет работать, но мы не хотим давать этим пользователям разрешения супер-администратор. Кто-нибудь знает какое-либо руководство или настройки для установки на этом?

1 Ответ

0 голосов
/ 24 марта 2020

Ответ:

Кроме Super Admin нет роли, которая позволила бы пользователю выполнять все эти действия. Вы можете проверить это путем назначения пользовательских ролей администратора пользователю. Даже если проверены все возможные привилегии, если пользователь не является Super Admin, он не может выступать в роли администратора домена в Classroom API.

Что могут делать не суперадминистраторы:

Пользователи без прав администратора могут получить доступ только к курсам, которые им принадлежат , но не ко всем курсам в домене.

Они могут удалять учеников и других учителей из своих курсов напрямую через courses.teachers.delete и courses.students.delete , но они не могут напрямую добавить новых студентов и преподавателей к своим курсам через courses.teachers.create и courses.students.create . Это могут делать только администраторы домена (Super Admins). Не администраторы должны сначала отправить приглашение через invitations.create () и получить согласие пользователя.

Обновление: учетные записи служб:

Вы также можете подать заявку используйте служебную учетную запись, чтобы выдать себя за Супер Администратора, чтобы эта учетная запись могла действовать от имени этого администратора, и делать то, что может делать администратор. Для этого вам необходимо создать учетную запись службы и делегировать ей полномочия на уровне домена , посетив консоль администратора и выполнив указанные шаги здесь .

Осторожно, предоставление делегирования для всего домена - это очень мощный инструмент , поскольку он дает учетной записи службы возможность действовать от имени любого пользователя. в домене , поэтому его можно было бы легко использовать, если не управлять им осторожно (без делегирования по всему домену служебная учетная запись похожа на обычную учетную запись и может получать доступ только к созданным ресурсам. ей, поделились с ней, и т. д. c., как обычная учетная запись).

В любом случае, после создания делегирования на уровне домена использование служебной учетной записи в вашем приложении очень похоже на использование обычной Счет. В приложении необходимо создать учетные данные, а затем указать, какой пользователь должен выдавать себя за учетную запись, написав адрес электронной почты пользователя. Я не знаю, какой язык вы используете, но вы можете найти фрагменты кода, чтобы сделать это в Java и Python здесь , или с узлом здесь .

Ссылка:

...