Предоставление временного доступа для клиентов

[SK]

этим заниматся должен тот кого клиент назначит. Назначит диспетчера, дадут ему права и будет делать. скажут админу -значит админу.

Но тогда диспетчер получит доступ к админской оснастке. Где здесь правильность ?
Почему диспетчер должен получать для решения этой задачи доступ к оснастке администрирования пользователей ?

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

Логично, что админ должен иметь доступ к списку "временных гостей".
Возможно, следует сделать доступ к нему как-то более удобно для админа.
Но мне не совсем понятно, почему этот список следует смешать со списком пользователей системы ?
Реальных пользователей системы может быть всего 10, а "временных гостей" - десятки и более на тот или иной момент времени.

И вообще я сильно подозреваю, что "временные гости" и "временные пользователи" от csistra - два совершенно разных класса пользователей системы.

Сергей, Вы можете описать своих "временных пользователей" ?
Их роль и функции ?
Для чего дается им доступ, к чему, с какими правами и почему временно ?
Почему именно логин/пароль, а не токен ?
В чем их связь с AD (учитывая, что их логин уничтожается потом) ?

Вы поймите: мы четко представляем - для чего и для кого именно делалась эта функция. А Ваше применение и, поэтому, Ваше желание сделать это по-другому - мы не совсем понимаем, может, потому, что не думали о таком применении, которое нужно Вам. Помогите нам разобраться.

[csistra]

Но тогда диспетчер получит доступ к админской оснастке. Где здесь правильность ?

эх....
получить доступ к оснастке не значит получить права на администрирование сервиса.
А правильность в том, что все находится в одном месте, а не распылено по разным местам.

Возможно, следует сделать доступ к нему как-то более удобно для админа.

Возможно все-таки единая точка администрирования сервиса который включит в себя:
1.Веб.
2.Клиентский АГ
3.Функционал выдачи токенов временным пользователям.
лучше чем 3 точки администрирования по сути 1 сервиса ?

Но мне не совсем понятно, почему этот список следует смешать со списком пользователей системы ?

А чем отличается пользователь системы и временный пользователь ?
По сути только 1 признаком - срок действия учетной записи.
У штатного пользователя данный признак стоит never. У временного стоит дата.
Ограничение по доступности техники по сути различий между ними не делает.

Реальных пользователей системы может быть всего 10, а "временных гостей" - десятки и более на тот или иной момент времени.

Например есть компания, скажем 1000 пользователей.
Поднят домен.
Каждый день кто то увольняется, кого то принимают на работу, приходят всякие аудиторы...
все то-же самое и тут....

И вообще я сильно подозреваю, что "временные гости" и "временные пользователи" от csistra - два совершенно разных класса пользователей системы.

Пользователь это пользователь, а какие у него полномочия это и делает отличия.
пользователь может иметь полномочия админа, гостя и т.п.
но суть не меняется - все это пользователи.

Сергей, Вы можете описать своих "временных пользователей" ?

у меня нет моих временных пользователей.
Когда мне надо дать временно кому то доступ я даю доступ и выставляю срок действия логина до определенной даты.

В чем их связь с AD (учитывая, что их логин уничтожается потом) ?

связь с ад дает простоту администрирования.
Достаточно в АД любому пользователю добавить группу доступа к сервису и он сможет войти, получить данные и т.п.
Логин подчищается регламентно.
Плюс еще в том что все логируется.

мы четко представляем - для чего и для кого именно делалась эта функция

Угу.

А Ваше применение и, поэтому, Ваше желание сделать это по-другому

Не по другому. а централизовано. Т.е. управление сервисом в 1м месте.
Вы берете и налепливаете кучу модулей управления которые мало того, что между собой не связаны по сути.

мы не совсем понимаем

Откройте MSSQL например и посмотрите SECURITY. все управляется с ОДНОГО места к ЛЮБОЙ БАЗЕ в ОДНОМ месте.

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

То что нужно мне в этой теме не обсуждается.

завтра позвоню так будет проще.

[SK]

Цитата:
Сообщение от SK
мы не совсем понимаем
Откройте MSSQL например и посмотрите SECURITY. все управляется с ОДНОГО места к ЛЮБОЙ БАЗЕ в ОДНОМ месте.

Хороший пример. Показательный.
Воспользуемся им: система 1С - со своими пользователями. Все они имеют по сути доступ к базе MSSQL. Почему не сделать администрирование их в одном месте в MSSQL ? Зачем в 1С - своя система пользователей ? Зачем её нагородили ?

Другой пример: предприятие. Есть отдел кадров и работники. Есть временные пропуска для посетителей. Их выдают от разных отделов для разных целей. С точки зрения проходной - все эти люди одинаковые просто с разными пропусками (правами). Нужно ли отделу кадров предприятия иметь у себя в списке работников еще и все эти временные пропуска ?

Я же говорю: что допускаю, что для админа следует видеть две вкладки, грубо говоря: "пользователи" и "гости". Но смешивать их в один список - имхо не совсем корректно и удобно.
Админ видит обе вкладки, уполномоченные управлять "гостями" - только одну - "гости", например.

[SK]

csistra, до меня только сейчас, сорри, дошло... что Вы не смотрели, похоже, ссылки, которые давал Денис - которые раскрывают возможности этих токенов = "гостей".
Отсюда и Ваше непонимание функции этого сервиса, вызывающее в свою очередь моё непонимание...

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

Вы, похоже, решили, что это именно "пользователь", с тем интерфейсом, который предоставляет веб, настроенном админом под этого "гостя"... это не так.
Это совсем для других целей.

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

[csistra]

Воспользуемся им: система 1С - со своими пользователями. Все они имеют по сути доступ к базе MSSQL. Почему не сделать администрирование их в одном месте в MSSQL ? Зачем в 1С - своя система пользователей ? Зачем её нагородили ?

Не сделать потому что 1С разрабатывает 1 компания а MSSQL совершено другая.
Но тот же 1С замечательно синхронизируется с АД к примеру.

Админ видит обе вкладки, уполномоченные управлять "гостями" - только одну - "гости", например.

Совершенно верно.
И эти обе вкладки находятся в 1 оснастке.

сорри, дошло... что Вы не смотрели, похоже, ссылки, которые давал Денис - которые раскрывают возможности этих токенов

смотрел, бегло но смотрел, общий смысл понятен.

Вы, похоже, решили, что это именно "пользователь", с тем интерфейсом, который предоставляет веб, настроенном админом под этого "гостя"... это не так.
Это совсем для других целей.

Нет я так не решил.
Я понимаю зачем это, вопрос не в этом.
Вопрос в том, чтобы все, что связано с админисртированием сервиса АвтоГраф было в одном месте и все.

[SK]

Вопрос в том, чтобы все, что связано с админисртированием сервиса АвтоГраф было в одном месте и все.

Проблема в том, что мы и наши клиенты не считают эту функцию "администрированием". Они считают её функцией и оснасткой - для диспетчеров.
Диспетчеры выдают эти ссылки и управляют ими в процессе работы, а не админы.

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

[csistra]

Значит будет очередной кусочно лоскутный вариант.

[denisio]

Сообщение от SK

В чем их связь с AD (учитывая, что их логин уничтожается потом) ?

связь с ад дает простоту администрирования.
Достаточно в АД любому пользователю добавить группу доступа к сервису и он сможет войти, получить данные и т.п.
Логин подчищается регламентно.
Плюс еще в том что все логируется.

Интеграци с доменом стоит в планах задач.