Просмотр полной версии : Предоставление временного доступа для клиентов
Подскажите пожалуйста, как реализовать следующее:
Необходимо предоставлять временный доступ (генерировать логин и пароль на определенный период или по достижении конкретной точки) и высылать его по эл.почте или смс клиенту которому везется груз. Клиент в течении данного периода может просматривать в веб. морде движение ТС.
В идеале все делается автоматически!
Я ТОЧНО в какой-то статье в Интернете видел и заходил на подобный веб-сервис 2-3 месяца назад, но сейчас никак не могу нагуглить. Он был совместим со многими системами мониторинга в т.ч. и АвтоГРАФ-ом.
Может кто подскажет реализацию данной фичи ?
Дилер ничего подсказать мне не смог!
P.S. если не получиться придётся делать самому!
NickolaDed
03.04.2015, 14:09
Был такой проект грузолот, но вроде как он сдох еще год назад
Спасибо!
Но что-другое было !
Подскажите пожалуйста, как реализовать следующее:
Необходимо предоставлять временный доступ (генерировать логин и пароль на определенный период или по достижении конкретной точки) и высылать его по эл.почте или смс клиенту которому везется груз. Клиент в течении данного периода может просматривать в веб. морде движение ТС.
В идеале все делается автоматически!
Я ТОЧНО в какой-то статье в Интернете видел и заходил на подобный веб-сервис 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
denisio, да вот не то это... вроде бы...
надо чтобы клиент не видел трек, кроме этих рамок... вот едет груз - например 1 и 2 мая, сделал ему доступ, и вот хоть убей, но 3 мая и 30 апреля он не увидит - вот так надо.
NickolaDed
03.04.2015, 19:56
токен так и позволит делать. Только вот команда в открытом виде, даты в открытом виде. Вот если бы можно было выдать ссылку с зашифровонной командой в каторой и токен и другие парамтры
токен так и позволит делать. Только вот команда в открытом виде, даты в открытом виде. Вот если бы можно было выдать ссылку с зашифровонной командой в каторой и токен и другие парамтры
Возможно, надо было обвести чуть жирнее.
http://ybex.com/index.php?c=start&m=pic&key=uwm0xkmdmv6bwn3ydkqykxr4no502ky4hhff60sg
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, думаю, он имеет ввиду это:
<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 - это и есть ограничения по времени для клиента.
В смысле, что подставив туда любые нужные даты, можно посмотреть чужие треки по машинкам из токена.
Ничо подобного. Если для аккаунта или токена выставлены ограничения - то параметры в урле не помогут.
Если для аккаунта или токена выставлены ограничения - то параметры в урле не помогут.
А внутри диапазона ограничений токена эти параметры будут работать ?
Если для аккаунта или токена выставлены ограничения - то параметры в урле не помогут.
А внутри диапазона ограничений токена эти параметры будут работать ?
Внутри будут. Параметры в урле имеют самый низкий приоритет и принимаются к расчетам только после проверки всего остальное. Порядок проверки такой:
1) права и ограничения пользователя, который в токене
2) самого параметров токена
3) параметры в урле
То же самое касается и номеров приборов, если они используются.
По сути есть БД с заказами, там же есть контактные данные, там же есть крайний срок исполнения заявки и её статусы, там же указывается какая машина взяла груз ( ттн или что там еще есть).
Соответственно нужно с этой базы выдать доступ к АГ Веб на основе:
1.мыло клиента.
2.номер машины с ттн.
3.сроки выполнения заявки.
Соответственно нужно допиливание базы в которой все ведется.
Соответственно нужно допиливание самого АГ, чтобы тот умел:
1.Принимать внешние скрипты на админ, или синхронихироватся с АД например.
Ограничение времени доступа к АГ можно и по шедулеру сделать который есть в АД.
Т.е. основная работа будет не в АГ а в базе где ведут все заявки.
По сути есть БД с заказами, там же есть контактные данные, там же есть крайний срок исполнения заявки и её статусы, там же указывается какая машина взяла груз ( ттн или что там еще есть).
Соответственно нужно с этой базы выдать доступ к АГ Веб на основе:
1.мыло клиента.
2.номер машины с ттн.
3.сроки выполнения заявки.
Соответственно нужно допиливание базы в которой все ведется.
Соответственно нужно допиливание самого АГ, чтобы тот умел:
1.Принимать внешние скрипты на админ, или синхронихироватся с АД например.
Ограничение времени доступа к АГ можно и по шедулеру сделать который есть в АД.
Т.е. основная работа будет не в АГ а в базе где ведут все заявки.
ну для этого надо дернуть метод на сервере, который вернёт токен. Могу документировать сие в раздел "Интеграция" ближе к вечеру.
ну для этого надо дернуть метод на сервере, который вернёт токен. Могу документировать сие в раздел "Интеграция" ближе к вечеру.
ЭМ... я не совсем это имею ввиду.
Скриптом заводится пользователь, где:
1.Имя пользователя - почта контактного лица.
2.Пароль - случайный вариатор.
3.Доступная техника - из ттн заявки.
4.Срок действия (жизни) пользователя крайний срок заявки + 3 дня (к примеру).
Т.е. в любом случае с основным софтом завязывать придётся.
Добавлено через 52 секунды
Далее пользователю на почту падает линк.
Только логин и пас ему не надо вбивать, т.к. это зашивается в линк на АГ в виде хеша.
Всем удобно и красиво.
Добавлено через 1 минуту
Главное, что заморачиватся по администрированию особо не потребуется, старые пользователи просто по дате блочатся да и все.
Можно еще дополнить плановым скриптом на очистку заблокированных пользователей, т.к. помойка будет расти. Раз в квартал к примеру запускается скрипт который удаляет пользователей с признаком "заблокировано".
Добавлено через 38 секунд
Могу документировать сие в раздел "Интеграция" ближе к вечеру.
Лучше сделайте юзер менеджер нормальный.
ну для этого надо дернуть метод на сервере, который вернёт токен. Могу документировать сие в раздел "Интеграция" ближе к вечеру.
ЭМ... я не совсем это имею ввиду.
Скриптом заводится пользователь, где:
1.Имя пользователя - почта контактного лица.
2.Пароль - случайный вариатор.
3.Доступная техника - из ттн заявки.
4.Срок действия (жизни) пользователя крайний срок заявки + 3 дня (к примеру).
Т.е. в любом случае с основным софтом завязывать придётся.
Все 4 пункта достаточно легко сделать в виде одного вызова веб-интерфейса. В результате веб, например, будет возвращать ссылку с токеном или просто токен.
хорошо, а это будет связано с юзерменеджером ?
Добавлено через 26 секунд
или это просто будет автономная доработка для веба и ни с чем не связанная ?
csistra, а почему это связано с юзерменеджером ? Особенно, если ссылки чаще всего предоставляются соврешенно левым людям / компаниям, которые никаким образом в юзеры не попадают...
В других системах эти токены никак на юзеров не завязаны, разве это неправильно ?
В других системах эти токены никак на юзеров не завязаны, разве это неправильно ?
почему же неправильно, правильно, но монета имеет две стороны.
csistra, поясните, пожалуйста, Ваше высказывание.
Наша задача:
1. Выдача временного доступа к заданной технике по токену - для "гостей".
Ваша задача, если я правильно понял:
2. То же самое, но с выдачей логина и пароля вместо токена.
2. То же самое, но с выдачей логина и пароля вместо токена.
угу, что тянет за собой нормальную оснастку для администрирования и связку с АД
2. То же самое, но с выдачей логина и пароля вместо токена.
угу, что тянет за собой нормальную оснастку для администрирования и связку с АД
Подождите. Связка с AD вовсе не является обязательной для такой схемы работы. Выдавать логин и пароль вместо токена (который по сути и является логином и паролем в одном флаконе) можно и без этого. Как выдача временного доступа связана с AD ?
в моем видении администрирование в нормальной оснастке + связка с АД позволит решить не только выдачу временных доступов но и постоянных, иначе давайте посмотрим что получается:
1.в вебе своя оснастка администрирования.
2.в Net своя (usermanager).
3. плюс оснастка для выдачи временных доступов.
не многовато ли ?
помоему перебор.
3. плюс оснастка для выдачи временных доступов.
Ну она же не имеет по сути отношения к работе с юзерами. С точки зрения её основного функционального назначения.
Я бы сказал, что администрирование пользователей и выдача временных доступов, например, в грузоперевозочной компании клиентам - совсем разные функции.
С юзерами должен работать админ, а выдавать временные токены "гостям" (клиентам) может и диспетчер, причем автоматически на основе назначенной клиенту машинки.
Поэтому, пихать их в одну оснастку - сильно-сильно некорректно.
Согласны ?
нет не согласен, работа с постоянными пользователями и правами, как и работа с временными это все попадает под понятие - адмнистрирование доступа к сервису.
поэтому мое мнение, что это должно быть в одной оснастке.
Добавлено через 49 секунд
иначе это кусочно лоскутный метод.
Хочешь это ? это в том блокнотике надо прописать.
надо другое ? в другом блокнотике поправить...
NickolaDed
07.04.2015, 09:18
иначе это кусочно лоскутный метод.
Импрессионизм в проектирование ПО
Просто моя позиция в подобных вопросах следующая, лучше нагрузить програмера на неделю и он это сделает 1 раз нормально, чем куча народу будет тратить в разы больше времени когда будет работать с кусочно лоскутными вещами.
нет не согласен, работа с постоянными пользователями и правами, как и работа с временными это все попадает под понятие - адмнистрирование доступа к сервису.
Еще раз поясняю: сидят диспетчеры, отправляют грузы по клиентам, формируют и дают ссылку с токеном этим клиентам. Ну нет тут админов.
А Вы предлагаете их загнать в админскую оснастку.
Это не программер делал "не нормально", потому что не был нагружен этим плотно неделю, а такова и была "задумка", что эта функция может и должна быть доступна не только админам. Но как тогда её сделать доступной не только админам ? Разве это вариант - пускать не-админов в админскую оснастку ?
P.S.: Как вариант, это может быть, допустим (я только пока теоретизирую), визуально сделано на соседних вкладках с управлением пользователями. Вкладка "юзеры" и вкладка "гости".
Мне просто не совсем Ваша концепция понятна. Обычно, список пользователей системы - он более-менее - постоянная штука. А вот такие "пользователи на 5 дней", у которых потом их логин автоматически уничтожается - это не совсем этот список. Это по сути не пользователи, а те же токены, выраженные в виде логин/пароля, а не токена.
все основано на логике, если котлеты то должны лежать с котлетами а не с фруктами, а мясные или рыбные -неважно, котлеты с котлетами!
так и здесь, предоставление постоянного или временного доступа это есть механизм администрирования сервиса , следовательно он должен быть единый.
Вот у вас есть комп, вы под учеткой гостя, вы можете посмотреть свойства пользователя админ например ? нет не можете! а почему ? да потому, что нету прав. А админ может посмотреть свойства профиля юзера например ? может! а почему ? да потому, что у него есть на это права.
Тоже самое и здесь.
Суть выдачи временного доступа или постоянного одна - администрирование и этим все сказано.
Добавлено через 3 минуты
Я просто знаю, что будет дальше.
А дальше будет повторена судьба usermanager, который сейчас не пришей рукав к штанине, а не средство администрирования.
А чтобы не было скушно в Web есть своя Приблуда для администрирования.
А чтобы раздать пользователям доступ терминально на серваке, надо воспользоватся бубном и оснастками AD.
В итоге, вместо понятного механизма получаем творчество группы коловрат с припевом "там потряси, здесь поверти".
так и здесь, предоставление постоянного или временного доступа это есть механизм администрирования сервиса , следовательно он должен быть единый.
Сергей, Вы просто не читаете, что я писал про транспортные компании и диспетчеров, потому что это не вписывается в Вашу концепцию, так ?
А ведь предоставление временного доступа изначально требовалось именно для этого - чтобы клиент мог отследить свой груз. Неужели этим именно админ должен заниматься ???
У "конкурентов", в т.ч. европейских и американских - это реализовано так же, как и у нас - отдельно. Причем мы не подсматривали в их системы. Может они из тех же соображений так делали ?
потому что это не вписывается в Вашу концепцию, так ?
нет не так.
Неужели этим именно админ должен заниматься ???
этим заниматся должен тот кого клиент назначит. Назначит диспетчера, дадут ему права и будет делать. скажут админу -значит админу.
европейских и американских - это реализовано так же, как и у нас - отдельно
у них много чего нареализовано, только в России нихрена не работает как ни странно, я примеров могу десятка два навскидку привести.
в общем, как хотите так и делайте. Я вас переубедить не смогу, так же как и вы меня, только разница в том, что вы можете сделать по своему, а мне ( нам всем) прийдется потом пользоваться, а нравится или не нравится неважно.
этим заниматся должен тот кого клиент назначит. Назначит диспетчера, дадут ему права и будет делать. скажут админу -значит админу.
Но тогда диспетчер получит доступ к админской оснастке. Где здесь правильность ?
Почему диспетчер должен получать для решения этой задачи доступ к оснастке администрирования пользователей ?
в общем, как хотите так и делайте. Я вас переубедить не смогу, так же как и вы меня, только разница в том, что вы можете сделать по своему, а мне ( нам всем) прийдется потом пользоваться, а нравится или не нравится неважно.
Логично, что админ должен иметь доступ к списку "временных гостей".
Возможно, следует сделать доступ к нему как-то более удобно для админа.
Но мне не совсем понятно, почему этот список следует смешать со списком пользователей системы ?
Реальных пользователей системы может быть всего 10, а "временных гостей" - десятки и более на тот или иной момент времени.
И вообще я сильно подозреваю, что "временные гости" и "временные пользователи" от csistra - два совершенно разных класса пользователей системы.
Сергей, Вы можете описать своих "временных пользователей" ?
Их роль и функции ?
Для чего дается им доступ, к чему, с какими правами и почему временно ?
Почему именно логин/пароль, а не токен ?
В чем их связь с AD (учитывая, что их логин уничтожается потом) ?
Вы поймите: мы четко представляем - для чего и для кого именно делалась эта функция. А Ваше применение и, поэтому, Ваше желание сделать это по-другому - мы не совсем понимаем, может, потому, что не думали о таком применении, которое нужно Вам. Помогите нам разобраться.
Но тогда диспетчер получит доступ к админской оснастке. Где здесь правильность ?
эх....
получить доступ к оснастке не значит получить права на администрирование сервиса.
А правильность в том, что все находится в одном месте, а не распылено по разным местам.
Возможно, следует сделать доступ к нему как-то более удобно для админа.
Возможно все-таки единая точка администрирования сервиса который включит в себя:
1.Веб.
2.Клиентский АГ
3.Функционал выдачи токенов временным пользователям.
лучше чем 3 точки администрирования по сути 1 сервиса ?
Но мне не совсем понятно, почему этот список следует смешать со списком пользователей системы ?
А чем отличается пользователь системы и временный пользователь ?
По сути только 1 признаком - срок действия учетной записи.
У штатного пользователя данный признак стоит never. У временного стоит дата.
Ограничение по доступности техники по сути различий между ними не делает.
Реальных пользователей системы может быть всего 10, а "временных гостей" - десятки и более на тот или иной момент времени.
Например есть компания, скажем 1000 пользователей.
Поднят домен.
Каждый день кто то увольняется, кого то принимают на работу, приходят всякие аудиторы...
все то-же самое и тут....
И вообще я сильно подозреваю, что "временные гости" и "временные пользователи" от csistra - два совершенно разных класса пользователей системы.
Пользователь это пользователь, а какие у него полномочия это и делает отличия.
пользователь может иметь полномочия админа, гостя и т.п.
но суть не меняется - все это пользователи.
Сергей, Вы можете описать своих "временных пользователей" ?
у меня нет моих временных пользователей.
Когда мне надо дать временно кому то доступ я даю доступ и выставляю срок действия логина до определенной даты.
В чем их связь с AD (учитывая, что их логин уничтожается потом) ?
связь с ад дает простоту администрирования.
Достаточно в АД любому пользователю добавить группу доступа к сервису и он сможет войти, получить данные и т.п.
Логин подчищается регламентно.
Плюс еще в том что все логируется.
мы четко представляем - для чего и для кого именно делалась эта функция
Угу.
А Ваше применение и, поэтому, Ваше желание сделать это по-другому
Не по другому. а централизовано. Т.е. управление сервисом в 1м месте.
Вы берете и налепливаете кучу модулей управления которые мало того, что между собой не связаны по сути.
мы не совсем понимаем
Откройте MSSQL например и посмотрите SECURITY. все управляется с ОДНОГО места к ЛЮБОЙ БАЗЕ в ОДНОМ месте.
не думали о таком применении, которое нужно Вам. Помогите нам разобраться.
То что нужно мне в этой теме не обсуждается.
завтра позвоню так будет проще.
Цитата:
Сообщение от SK
мы не совсем понимаем
Откройте MSSQL например и посмотрите SECURITY. все управляется с ОДНОГО места к ЛЮБОЙ БАЗЕ в ОДНОМ месте.
Хороший пример. Показательный.
Воспользуемся им: система 1С - со своими пользователями. Все они имеют по сути доступ к базе MSSQL. Почему не сделать администрирование их в одном месте в MSSQL ? Зачем в 1С - своя система пользователей ? Зачем её нагородили ?
Другой пример: предприятие. Есть отдел кадров и работники. Есть временные пропуска для посетителей. Их выдают от разных отделов для разных целей. С точки зрения проходной - все эти люди одинаковые просто с разными пропусками (правами). Нужно ли отделу кадров предприятия иметь у себя в списке работников еще и все эти временные пропуска ?
Я же говорю: что допускаю, что для админа следует видеть две вкладки, грубо говоря: "пользователи" и "гости". Но смешивать их в один список - имхо не совсем корректно и удобно.
Админ видит обе вкладки, уполномоченные управлять "гостями" - только одну - "гости", например.
csistra, до меня только сейчас, сорри, дошло... что Вы не смотрели, похоже, ссылки, которые давал Денис - которые раскрывают возможности этих токенов = "гостей".
Отсюда и Ваше непонимание функции этого сервиса, вызывающее в свою очередь моё непонимание...
Это не "обычный пользователь с ограничением по времени", это совсем другая штука в плане интерфейса отображения... урезанная по самый край по возможностям.
Вы, похоже, решили, что это именно "пользователь", с тем интерфейсом, который предоставляет веб, настроенном админом под этого "гостя"... это не так.
Это совсем для других целей.
Пользователи с ограничением по времени, отличающиеся от обычных пользователей собсно только ограничением по времени - конечно должны быть в списке пользователей.
Воспользуемся им: система 1С - со своими пользователями. Все они имеют по сути доступ к базе MSSQL. Почему не сделать администрирование их в одном месте в MSSQL ? Зачем в 1С - своя система пользователей ? Зачем её нагородили ?
Не сделать потому что 1С разрабатывает 1 компания а MSSQL совершено другая.
Но тот же 1С замечательно синхронизируется с АД к примеру.
Админ видит обе вкладки, уполномоченные управлять "гостями" - только одну - "гости", например.
Совершенно верно.
И эти обе вкладки находятся в 1 оснастке.
сорри, дошло... что Вы не смотрели, похоже, ссылки, которые давал Денис - которые раскрывают возможности этих токенов
смотрел, бегло но смотрел, общий смысл понятен.
Вы, похоже, решили, что это именно "пользователь", с тем интерфейсом, который предоставляет веб, настроенном админом под этого "гостя"... это не так.
Это совсем для других целей.
Нет я так не решил.
Я понимаю зачем это, вопрос не в этом.
Вопрос в том, чтобы все, что связано с админисртированием сервиса АвтоГраф было в одном месте и все.
Вопрос в том, чтобы все, что связано с админисртированием сервиса АвтоГраф было в одном месте и все.
Проблема в том, что мы и наши клиенты не считают эту функцию "администрированием". Они считают её функцией и оснасткой - для диспетчеров.
Диспетчеры выдают эти ссылки и управляют ими в процессе работы, а не админы.
Админы, конечно, должны иметь возможность, в случае чего, вмешаться, но, в первую очередь, это всё же диспетчерская оснастка.
Вмешательство админов здесь должно быть только в редких случаях.
Это всё же как бы не совсем пользователи.
Значит будет очередной кусочно лоскутный вариант. :temazakryta:
В чем их связь с AD (учитывая, что их логин уничтожается потом) ?
связь с ад дает простоту администрирования.
Достаточно в АД любому пользователю добавить группу доступа к сервису и он сможет войти, получить данные и т.п.
Логин подчищается регламентно.
Плюс еще в том что все логируется.
Интеграци с доменом стоит в планах задач.
vBulletin® v3.8.5, Copyright ©2000-2024, Jelsoft Enterprises Ltd. Перевод: zCarot