Какие разрешения требуются в вызове PUT для /courses в Desire2learn (D2L) Valence?

Я продолжаю получать ответ «HTTP/1.1 403 Forbidden» на запрос PUT к /d2l/api/lp/1.2/courses/7917 . Это может быть проблема с разрешениями для пользователя/роли, которые я использую, но я не могу понять, какие конкретные разрешения могут потребоваться. Может ли кто-нибудь указать мне список или матрицу маршрутов валентности и необходимых разрешений? Или ответить на этот конкретный?

Один и тот же appid/userid/username работает для GET, связанных с одним и тем же путем.

смущенный...

ЦВТ


person Chris Tatem    schedule 11.09.2013    source источник


Ответы (1)


Разрешения, связанные с вызовами API, должны отражать разрешения, которые вам понадобились бы, если бы вы выполняли соответствующую функцию через веб-интерфейс Learning Envrionment. Вы можете думать об этой проблеме двумя способами:

  • Сформулируйте вопрос с точки зрения роли пользователя: определите класс пользователей, для которого вы зарезервировали бы эту возможность в существующей конфигурации, и убедитесь, что пользователь с этой ролью может выполнять вызов через API, как вы ожидаете.

  • Сформулируйте вопрос с точки зрения абстрактного отдельного пользователя: начните с роли, у которой нет привилегий, и добавляйте разрешения, пока не получите только те, которые необходимы для вызова API. Это нетривиальное упражнение, и первый способ гораздо полезнее в долгосрочной перспективе.

В этом конкретном случае, поскольку API требует, чтобы вы предоставили полный курс, предлагающий набор свойств, когда вы хотите его обновить, у вас должно быть разрешение на изменение всех свойств в наборе (в инструменте Manage Courses ). Вы также должны иметь возможность просматривать информацию о курсе в первую очередь, поэтому вам также необходимо иметь Course Management Console > See Course Info.

Вероятно, безопаснее всего просмотреть массив разрешений в инструментах Manage Courses и Course Management Console для ролей пользователей, которые будут делать это в веб-интерфейсе, и убедиться, что пользователи, использующие ваше приложение, также имеют аналогичный массив разрешений, указанный в этих инструментах.

person Viktor Haag    schedule 11.09.2013
comment
Спасибо за это, в конце концов оказалось, что моя проблема была в моем (java) коде, где я пытался PUT использовать HTTP POST, не уверен, почему это привело к проблеме авторизации - я подозреваю, что токен был не там, где он должен быть. Я также нашел два конкретных разрешения для предложений (моя цель) для обновления. - person Chris Tatem; 11.09.2013
comment
Обратите внимание, что токены аутентификации для подписи пользователя и подписи приложения в запросах API основаны на использовании (частично) метода HTTP в базовой строке для подписи. Таким образом, если вы вызываете маршрут, который должен быть POST-маршрутом, и вы делаете это с помощью PUT, это, скорее всего, может быть отправлено обратно как 403 для недопустимых токенов в зависимости от того, как вы подписываете маршрут и как вы отправляете его в службу. - person Viktor Haag; 13.09.2013