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

Подскажите пожалуйста, как реализовать следующее:

Необходимо предоставлять временный доступ (генерировать логин и пароль на определенный период или по достижении конкретной точки) и высылать его по эл.почте или смс клиенту которому везется груз. Клиент в течении данного периода может просматривать в веб. морде движение ТС.

В идеале все делается автоматически!

Я ТОЧНО в какой-то статье в Интернете видел и заходил на подобный веб-сервис 2-3 месяца назад, но сейчас никак не могу нагуглить. Он был совместим со многими системами мониторинга в т.ч. и АвтоГРАФ-ом.

Может кто подскажет реализацию данной фичи ?
Дилер ничего подсказать мне не смог!

P.S. если не получиться придётся делать самому!

Был такой проект грузолот, но вроде как он сдох еще год назад

Спасибо!
Но что-другое было !

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



Результат:

denisio, да вот не то это... вроде бы...

надо чтобы клиент не видел трек, кроме этих рамок... вот едет груз - например 1 и 2 мая, сделал ему доступ, и вот хоть убей, но 3 мая и 30 апреля он не увидит - вот так надо.

токен так и позволит делать. Только вот команда в открытом виде, даты в открытом виде. Вот если бы можно было выдать ссылку с зашифровонной командой в каторой и токен и другие парамтры

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

denisio, думаю, он имеет ввиду это:
Что sd и ed - это и есть ограничения по времени для клиента.
В смысле, что подставив туда любые нужные даты, можно посмотреть чужие треки по машинкам из токена.

Ничо подобного. Если для аккаунта или токена выставлены ограничения - то параметры в урле не помогут.

А внутри диапазона ограничений токена эти параметры будут работать ?

Внутри будут. Параметры в урле имеют самый низкий приоритет и принимаются к расчетам только после проверки всего остальное. Порядок проверки такой:
1) права и ограничения пользователя, который в токене
2) самого параметров токена
3) параметры в урле

То же самое касается и номеров приборов, если они используются.

По сути есть БД с заказами, там же есть контактные данные, там же есть крайний срок исполнения заявки и её статусы, там же указывается какая машина взяла груз ( ттн или что там еще есть).
Соответственно нужно с этой базы выдать доступ к АГ Веб на основе:
1.мыло клиента.
2.номер машины с ттн.
3.сроки выполнения заявки.
Соответственно нужно допиливание базы в которой все ведется.
Соответственно нужно допиливание самого АГ, чтобы тот умел:
1.Принимать внешние скрипты на админ, или синхронихироватся с АД например.

Ограничение времени доступа к АГ можно и по шедулеру сделать который есть в АД.
Т.е. основная работа будет не в АГ а в базе где ведут все заявки.

ну для этого надо дернуть метод на сервере, который вернёт токен. Могу документировать сие в раздел "Интеграция" ближе к вечеру.

ЭМ... я не совсем это имею ввиду.
Скриптом заводится пользователь, где:
1.Имя пользователя - почта контактного лица.
2.Пароль - случайный вариатор.
3.Доступная техника - из ттн заявки.
4.Срок действия (жизни) пользователя крайний срок заявки + 3 дня (к примеру).

Т.е. в любом случае с основным софтом завязывать придётся.

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

Добавлено через 1 минуту
Главное, что заморачиватся по администрированию особо не потребуется, старые пользователи просто по дате блочатся да и все.
Можно еще дополнить плановым скриптом на очистку заблокированных пользователей, т.к. помойка будет расти. Раз в квартал к примеру запускается скрипт который удаляет пользователей с признаком "заблокировано".

Добавлено через 38 секунд
Лучше сделайте юзер менеджер нормальный.

Все 4 пункта достаточно легко сделать в виде одного вызова веб-интерфейса. В результате веб, например, будет возвращать ссылку с токеном или просто токен.

хорошо, а это будет связано с юзерменеджером ?

Добавлено через 26 секунд
или это просто будет автономная доработка для веба и ни с чем не связанная ?

csistra, а почему это связано с юзерменеджером ? Особенно, если ссылки чаще всего предоставляются соврешенно левым людям / компаниям, которые никаким образом в юзеры не попадают...
В других системах эти токены никак на юзеров не завязаны, разве это неправильно ?

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

csistra, поясните, пожалуйста, Ваше высказывание.
Наша задача:
1. Выдача временного доступа к заданной технике по токену - для "гостей".
Ваша задача, если я правильно понял:
2. То же самое, но с выдачей логина и пароля вместо токена.

угу, что тянет за собой нормальную оснастку для администрирования и связку с АД

Подождите. Связка с AD вовсе не является обязательной для такой схемы работы. Выдавать логин и пароль вместо токена (который по сути и является логином и паролем в одном флаконе) можно и без этого. Как выдача временного доступа связана с AD ?

в моем видении администрирование в нормальной оснастке + связка с АД позволит решить не только выдачу временных доступов но и постоянных, иначе давайте посмотрим что получается:
1.в вебе своя оснастка администрирования.
2.в Net своя (usermanager).
3. плюс оснастка для выдачи временных доступов.
не многовато ли ?
помоему перебор.

Ну она же не имеет по сути отношения к работе с юзерами. С точки зрения её основного функционального назначения.

Я бы сказал, что администрирование пользователей и выдача временных доступов, например, в грузоперевозочной компании клиентам - совсем разные функции.

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

Поэтому, пихать их в одну оснастку - сильно-сильно некорректно.
Согласны ?

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

Добавлено через 49 секунд
иначе это кусочно лоскутный метод.
Хочешь это ? это в том блокнотике надо прописать.
надо другое ? в другом блокнотике поправить...

Импрессионизм в проектирование ПО

Просто моя позиция в подобных вопросах следующая, лучше нагрузить програмера на неделю и он это сделает 1 раз нормально, чем куча народу будет тратить в разы больше времени когда будет работать с кусочно лоскутными вещами.

Еще раз поясняю: сидят диспетчеры, отправляют грузы по клиентам, формируют и дают ссылку с токеном этим клиентам. Ну нет тут админов.
А Вы предлагаете их загнать в админскую оснастку.

Это не программер делал "не нормально", потому что не был нагружен этим плотно неделю, а такова и была "задумка", что эта функция может и должна быть доступна не только админам. Но как тогда её сделать доступной не только админам ? Разве это вариант - пускать не-админов в админскую оснастку ?

P.S.: Как вариант, это может быть, допустим (я только пока теоретизирую), визуально сделано на соседних вкладках с управлением пользователями. Вкладка "юзеры" и вкладка "гости".

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

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

Добавлено через 3 минуты
Я просто знаю, что будет дальше.
А дальше будет повторена судьба usermanager, который сейчас не пришей рукав к штанине, а не средство администрирования.
А чтобы не было скушно в Web есть своя Приблуда для администрирования.
А чтобы раздать пользователям доступ терминально на серваке, надо воспользоватся бубном и оснастками AD.
В итоге, вместо понятного механизма получаем творчество группы коловрат с припевом "там потряси, здесь поверти".

Сергей, Вы просто не читаете, что я писал про транспортные компании и диспетчеров, потому что это не вписывается в Вашу концепцию, так ?

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

У "конкурентов", в т.ч. европейских и американских - это реализовано так же, как и у нас - отдельно. Причем мы не подсматривали в их системы. Может они из тех же соображений так делали ?

нет не так.


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


у них много чего нареализовано, только в России нихрена не работает как ни странно, я примеров могу десятка два навскидку привести.

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

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

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

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

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

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

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


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


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


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


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


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




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


Угу.


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


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


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

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

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

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

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

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

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

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

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

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


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


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


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

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

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

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

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