Лёгкое программирование под Autodesk Vault. Часть 13

Автор Тема: Лёгкое программирование под Autodesk Vault. Часть 13  (Прочитано 5370 раз)

0 Пользователей и 2 Гостей просматривают эту тему.

Оффлайн Александр РивилисАвтор темы

  • Administrator
  • *****
  • Сообщений: 13882
  • Карма: 1787
  • Рыцарь ObjectARX
  • Skype: rivilis
« Последнее редактирование: 13-04-2014, 19:34:11 от Александр Ривилис »
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение

Оффлайн Андрей Кузнецов

  • ADN Club
  • Сообщений: 2
  • Карма: 0
Вопрос как получить список групп и пользователей в группе не имея роли Администратора?

ACW.Group group = WS.AdminService.GetGroupByName("Архитекторы");
ACW.GroupInfo grpInfo = WS.AdminService.GetGroupInfoByGroupId(group.Id);
ACW.Group[] groups = grpInfo.Groups;
ACW.User[] users = grpInfo.Users;

Для вызова метода GetGroupByName необходимы (из документации):
Цитировать
Required Permissions
UserRead if logged in user is a member of the group. Otherwise AdminUserRead is required.

Но если плагин (пусть этот плагин должен отправить уведомления архитекторам) должен запустить допустим сотрудник "Архива". Зачем ему быть в группе "Архитекторы"??

Но дальше всё сложней! Даже если пользователь будет находится в группе "Архитекторы", то следующий метод GetGroupInfoByGroupId падает:
Цитировать
Required Permissions
AdminUserRead

Не жирно ли быть Архивариусу Admin-ом? Или есть нормальный способ получить информацию о пользователях?

Оффлайн Дмитрий Емельянов

  • Administrator
  • Сообщений: 38
  • Карма: 7
Андрей, добрый день!

Как вы легко можете проверить (например, зайдя в Vault Explorer от имени простого пользователя в меню "Глобальные параметры"), не-администратор не имеет возможности для просмотра пользователей, групп и ролей/прав. Попытка выполнить подобную операцию приводит к ошибке 303.

Решить данную проблему можно:
  • попросив Autodesk внести изменения в SDK - на что компания очень вряд ли пойдет, так как это затрагивает базовые вопросы безопасности
  • пересмотрев логику самого приложения
Второй способ наиболее приемлемый. Так, можно:
  • переложить вызов методов, требующих повышенных прав, на JobProcessor. При этом от имени пользователе будут только формироваться задания для JP
  • при запуске от имени администратора требуемая информация выкладывается в общедоступном месте: либо в локальной сети, либо в пользовательских свойствах в параметре "Значения списка"
На всякий случай я задал вопрос Дагу в его блоге.
На то время, пока он будет составлять ответ, сделал подборку интересных статей оттуда же:

Оффлайн Андрей Кузнецов

  • ADN Club
  • Сообщений: 2
  • Карма: 0
Мне понятно откуда возникает эта ошибка, не хочу вдаваться в тему "безопасно или нет получение пользователем списков групп и пользователей" не имея особой роли, пусть эта роль будет. Но это же не должна быть роль "Администратор"!

Решение переложить на Job-ы в данном случае не подходит.. Пользователю нужно выбрать кому отправлять или каким группам отправлять. Для этого нужно показать этот список. Ну и можно придумать большое количество задач, где нужен такой выбор.

На текущий момент есть решение использовать другую учетную запись.. Приведу цитату из документации:
Цитировать
Here is a common problem. You have a custom command that you want people to
use, but it does something that requires admin privileges. Making everyone
an administrator is a bad idea. A better solution is for your command to
perform an action as another user.

Vault doesn't support a true impersonation model, but there is a workaround
that works pretty well. Just have your program log in as another user to
perform the special task. Log out as soon as the task is done and let the
rest of the operations be performed by the logged-in user.

Recycle Bin 2.0 makes liberal use of this technique. The whole program rests
on a special "Recycle Bin" folder where files go before they are deleted.
Obviously this folder needs to be locked down from normal use. All
interaction with the Recycle Bin folder needs to be through one of the
custom commands. To enforce this, the administrator needs to designate a
special Recycle Bin User, which is the only one allowed to interact with the
Recycle Bin folder. Any time a Recycle Bin command is executed, the code
logs in as the Recycle Bin user in order to interact with the folder.

Considerations:

First, your code needs a way to know how to log in as the impersonated user.
In practice the impersonated  user is usually an administrator, so you have
to keep the password hidden from the end user. There are various ways to fix
this. You can hard-code the password, or you can encrypt the password and
put it in a common location.

Next, there is the issue of licensing. If you log in as two different users,
you will consume 2 licenses. If licenses are tight, then impersonation might
not be an option. Logging out the original user is not a good idea because
what if all the licenses are used up when the operation is over an they try
to log back in?
The best approach is to use the impersonated user only as long as needed.
When the operation is over, log out immediately to free up the license. If
all goes well, it shouldn't have a noticeable impact on the licenses being
consumed.
Also, make sure to handle errors properly. If errors come up during the
operation, you still want to make sure the impersonated user get logged out
at the end.

Lastly, impersonation has an impact on data history. Let's say you have an
operation that uses impersonation to move a file to the Released state.
Later in time you want to see who released a certain file. That becomes hard
to do since the history of the item will show the impersonated  user as the
one who made the change. What you want to see is the actual user.
This can be solved by storing the actual user as a piece of meta-data, such
as a UDP value. It's not a perfect workaround because the data you want is
not in the place where you expect it to be.

С точки зрения безопасности, предложенное решение куда хуже, нежели:
-либо специальная роль, дающая возможность readonly видеть какие-то части хранилища (назовем её ReadOnlyRole),
-либо непосредственно специальные методы API дающие такую возможность ( дополнительные методы из того же AdminService.. например GetReadOnlyGroupByName ) Vault Explorer по-прежнему вызывает GetGroupByName, а через API мы можем вызвать любой из этих 2-х

И если через API любой пользователь может "увидеть" эти данные (имея навыки программирования), то ReadOnlyRole устанавливается Админом. и он контролирует кому можно видеть такого рода информацию.

Ну или 3-й вариант - Метод GetReadOnlyGroupByName  доступен пользователю с ролью ReadOnlyRole
Такой подход более безопасен, чем предложенный в документации.

Не по теме: Капчу можно упростить? А то головоломки втоpой дeнь нeдeли, последний день недели, тpи+чeтыpе/двa*пять  (буkвaми).. )))

Оффлайн Александр РивилисАвтор темы

  • Administrator
  • *****
  • Сообщений: 13882
  • Карма: 1787
  • Рыцарь ObjectARX
  • Skype: rivilis
Андрей Кузнецов, это всё возможно правильно, но от нас не зависит. Можно передать это как пожелание в WishList, но только если сформулируешь его более четко и предложишь один конкретный вариант. Ну и само-собой если это пожелание будет принято, то появится в лучшем случае в следующей версии.
Не по теме: Капчу можно упростить? А то головоломки втоpой дeнь нeдeли, последний день недели, тpи+чeтыpе/двa*пять  (буkвaми).. )))
Больше ни капчи, ни головоломок не будет - они только в двух первых сообщениях пользователя. Упростить нельзя - у администрации форума нет желания тратить время на борьбу со спам-ботами - с этой проблемой мы столкнулись сразу после создания форума.
Не забывайте про правильное Форматирование кода на форуме
Создание и добавление Autodesk Screencast видео в сообщение на форуме
Если Вы задали вопрос и на форуме появился правильный ответ, то не забудьте про кнопку Решение