PDA

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


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

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

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

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

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

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

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

pan
03.04.2015, 14:23
Спасибо!
Но что-другое было !

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

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

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

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

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

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

Привет.
Да, такая возможность есть. В вебе можно создать токен с ограниченным сроком действия и выдать его клиенту для просмотра. Подробнее написано здесь (http://wiki.tk-chel.ru/index.php/%D0%98%D0%BD%D1%82%D0%B5%D0%B3%D1%80%D0%B0%D1%86%D 0%B8%D1%8F_%D1%81_%D1%81%D0%B0%D0%B9%D1%82%D0%B0%D 0%BC%D0%B8) или здесь (http://forum.tk-chel.ru/showthread.php?t=2870)

http://ybex.com/index.php?c=start&m=pic&key=w6z2l1ti0xjqa6ns97g58bm4h5z16hw84xh0yhk1

Результат:

http://wiki.tk-chel.ru/images/f/f1/Integrate_1.jpg

Yohnus
03.04.2015, 17:24
denisio, да вот не то это... вроде бы...

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

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

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

Возможно, надо было обвести чуть жирнее.
http://ybex.com/index.php?c=start&m=pic&key=uwm0xkmdmv6bwn3ydkqykxr4no502ky4hhff60sg

SK
05.04.2015, 14:12
denisio, думаю, он имеет ввиду это:
<iframe src='http://demo.tk-nav.com/Strict/Index/A6CB2007DD716D04B478C77AB929F1B8?map=osm&serials=9999986&sd=20140320&ed=20140321' width='600' height='600'></iframe>

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

denisio
05.04.2015, 18:01
denisio, думаю, он имеет ввиду это:
<iframe src='http://demo.tk-nav.com/Strict/Index/A6CB2007DD716D04B478C77AB929F1B8?map=osm&serials=9999986&sd=20140320&ed=20140321' width='600' height='600'></iframe>

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

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

SK
05.04.2015, 19:08
Если для аккаунта или токена выставлены ограничения - то параметры в урле не помогут.
А внутри диапазона ограничений токена эти параметры будут работать ?

denisio
06.04.2015, 05:55
Если для аккаунта или токена выставлены ограничения - то параметры в урле не помогут.
А внутри диапазона ограничений токена эти параметры будут работать ?

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

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

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

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

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

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

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

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

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

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

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

Добавлено через 38 секунд
Могу документировать сие в раздел "Интеграция" ближе к вечеру.
Лучше сделайте юзер менеджер нормальный.

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

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


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

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

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

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

csistra
06.04.2015, 20:05
В других системах эти токены никак на юзеров не завязаны, разве это неправильно ?
почему же неправильно, правильно, но монета имеет две стороны.

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

csistra
07.04.2015, 05:54
2. То же самое, но с выдачей логина и пароля вместо токена.
угу, что тянет за собой нормальную оснастку для администрирования и связку с АД

SK
07.04.2015, 06:09
2. То же самое, но с выдачей логина и пароля вместо токена.
угу, что тянет за собой нормальную оснастку для администрирования и связку с АД

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

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

SK
07.04.2015, 07:40
3. плюс оснастка для выдачи временных доступов.
Ну она же не имеет по сути отношения к работе с юзерами. С точки зрения её основного функционального назначения.

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

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

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

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

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

NickolaDed
07.04.2015, 09:18
иначе это кусочно лоскутный метод.
Импрессионизм в проектирование ПО

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

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

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

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

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

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

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

SK
07.04.2015, 13:18
так и здесь, предоставление постоянного или временного доступа это есть механизм администрирования сервиса , следовательно он должен быть единый.
Сергей, Вы просто не читаете, что я писал про транспортные компании и диспетчеров, потому что это не вписывается в Вашу концепцию, так ?

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

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

csistra
07.04.2015, 13:38
потому что это не вписывается в Вашу концепцию, так ?
нет не так.


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


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

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

SK
07.04.2015, 17:58
этим заниматся должен тот кого клиент назначит. Назначит диспетчера, дадут ему права и будет делать. скажут админу -значит админу.
Но тогда диспетчер получит доступ к админской оснастке. Где здесь правильность ?
Почему диспетчер должен получать для решения этой задачи доступ к оснастке администрирования пользователей ?

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

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

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

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

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

csistra
07.04.2015, 18:47
Но тогда диспетчер получит доступ к админской оснастке. Где здесь правильность ?
эх....
получить доступ к оснастке не значит получить права на администрирование сервиса.
А правильность в том, что все находится в одном месте, а не распылено по разным местам.


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


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


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


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


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




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


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


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


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


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

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

SK
07.04.2015, 19:13
Цитата:
Сообщение от SK
мы не совсем понимаем
Откройте MSSQL например и посмотрите SECURITY. все управляется с ОДНОГО места к ЛЮБОЙ БАЗЕ в ОДНОМ месте.
Хороший пример. Показательный.
Воспользуемся им: система 1С - со своими пользователями. Все они имеют по сути доступ к базе MSSQL. Почему не сделать администрирование их в одном месте в MSSQL ? Зачем в 1С - своя система пользователей ? Зачем её нагородили ?

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

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

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

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

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

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

csistra
08.04.2015, 05:47
Воспользуемся им: система 1С - со своими пользователями. Все они имеют по сути доступ к базе MSSQL. Почему не сделать администрирование их в одном месте в MSSQL ? Зачем в 1С - своя система пользователей ? Зачем её нагородили ?
Не сделать потому что 1С разрабатывает 1 компания а MSSQL совершено другая.
Но тот же 1С замечательно синхронизируется с АД к примеру.


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


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


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

SK
08.04.2015, 06:20
Вопрос в том, чтобы все, что связано с админисртированием сервиса АвтоГраф было в одном месте и все.
Проблема в том, что мы и наши клиенты не считают эту функцию "администрированием". Они считают её функцией и оснасткой - для диспетчеров.
Диспетчеры выдают эти ссылки и управляют ими в процессе работы, а не админы.

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

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

denisio
11.04.2015, 06:30
В чем их связь с AD (учитывая, что их логин уничтожается потом) ?
связь с ад дает простоту администрирования.
Достаточно в АД любому пользователю добавить группу доступа к сервису и он сможет войти, получить данные и т.п.
Логин подчищается регламентно.
Плюс еще в том что все логируется.

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