Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
В Wialon реализован новый более современный и безопасный способ авторизации.
Здесь постараемся ответить на все связанные вопросы и помочь со сложностями по его применению.
Статья в блоге
Файл с инструкциями
Подскажите, вот на этих страницах находится устаревшая информация по способу авторизации: http://sdk.wialon.com/wiki/ru/sidebar/r … core/login или этот способ можно использовать и после 1 октября?
Данный метод авторизации является устаревшим и будет работать до 1 октября.
На данный момент для авторизации в своих сайтах/аппсах нужно переходить на нашу
новую форму авторизации. Примеры использования есть на http://sdk.wialon.com/playground/.
После успешной авторизации через форму в ответе получается токен, который можно подать
в sdk-запрос wialon.core.Session.getInstance().loginToken() или remote-api запрос
http://hst-api.wialon.com/wialon/ajax.h … _token>
Добрый день!
Авторизуюсь в SDK запросом
http://hst-api.wialon.com/wialon/ajax.html?svc=core/login¶ms={"user":"****","password":"****"}
получаю "eid":"e7e7d0032cb8d2263c0f60e79d712f3f"
делаю запрос
http://hst-api.wialon.com/wialon/ajax.html?svc=token/update¶ms={"callMode":"create","userId":"***","h":"","app":"SDK_for_Apps","at":0,"dur":0,"fl":512,"p":"","items":[],"deleteAll":false}&sid=e7e7d0032cb8d2263c0f60e79d712f3f
получаю
{"error":7}
7 означает Доступ запрещен
Что делаю не так?
Данный путь не верный т.к. он перестанет работать 1 октября.
Запрос с core/login нужно исключить до этого времени.
Второй запрос token/update для управления токенами ПОСЛЕ авторизации.
Думаю он Вам не нужен.
Сначала нужно корректно авторизоваться используя форму http://hosting.wialon.com/login.html
В результате авторизации будет получен токен, который дальше можно использовать в запросе
svc=token/login¶ms={"token":<text>}. В результате этого запроса получите sid и дальше все запросы
выполняйте с этим sid-ом.
Посмотрите примеры на playground:
http://sdk.wialon.com/playground/demo/advanced_form
http://sdk.wialon.com/playground/demo/app_auth_token
Так я как раз и хочу создать токен средствами SDK! Получается в документации ошибка и я не смогу создать токен средствами SDK. На текущий момент авторизация работает и я могу выполнять ей все необходимые действия. Получается что для того чтобы создать токен нужно обязательно получить его через Web.
Что касается длительности действия Токенов - могу ли я задать её =0, чтобы он действовал бесконечно долго?
Вы можете создать токен средствами SDK (после авторизации).
В Вашем запросе нужно убрать userId (т.к. это для создания токена в другом пользователе), также на данный момент в "p" нужно подавать "{}" (пустой json). Параметр dur можно подать 0 - это т.н. бесконечный токен. Но если он не будет использоваться более 100 дней - автоматом удалится.
Подскажите после получения токена хочу сделать запрос remote_api:
http://hst-api.wialon.com/wialon/ajax.h … _token>
но откуда взять sid? раньше этот параметр возвращался запросом, о чем писал dencorp :
Авторизуюсь в SDK запросом
http://hst-api.wialon.com/wialon/ajax.html?svc=core/login¶ms={"user":"****","password":"****"}
получаю "eid":"e7e7d0032cb8d2263c0f60e79d712f3f"
то есть в eid, сейчас где его взять?
Для запроса token/login sid не нужен
Можно расценивать токен, как аналог пары/пароль.
Раньше для авторизации надо было знать логин/пароль, теперь - токен.
Раньше был запрос
http://hst-api.wialon.com/wialon/ajax.html?svc=core/login¶ms={"user":"****","password":"****"}
Теперь вместо него
http://hst-api.wialon.com/wialon/ajax.html?svc=token/login¶ms={"token":"****"}
Ответ сервера на эти запросы идентичен, в том числе в нём приходит eid для выполнения последующих запросов
это касается wialon pro также?
это касается wialon pro также?
Wialon Pro уже не дорабатывается, поэтому там механизм авторизации остался прежним.
Новый механизм авторизации коснулся Wialon Hosting и Wialon Local.
Здравствуйте!
Каким образом отработает система, если получение токена и последующий post-запрос на аутентификацию будут выполнены с разных адресов?
Чтобы не было недомолвок, поясню. Есть система, ну например, на базе 1С. Раз аутентификация на сервере невозможна и придется переносить ее на клиента, планирую на клиенте показать форму oAuth и передать полученный токен на сервер, на котором собственно и должны в дальнейшем обрабатываться данные. Возможен ли такой путь?
Вообще, надо сказать, что подобная аутентификация несколько осложнит взаимодействие со сторонними системами, например, той-же 1С. Теперь предстоят финты с полями html, скриптами и парсингом, то есть не типичный сценарий для 1С, без гарантированного 100% успешного результата.
IP адрес имеет значение только для активной сессии. А так токены можно получать в одном месте, а использовать - в другом.
IP адрес имеет значение только для активной сессии. А так токены можно получать в одном месте, а использовать - в другом.
Спасибо. Правильно ли я понял, что токен не имеет отношения к идентификации конкретной сессии, а представляет собой просто зашифрованную пару логин-пароль, плюс может быть какая-нибудь приправка? И единожды созданный токен, я могу использовать в течение 100 дней, без повторной аутентификации пользователя? Притом, зная этот самый токен, например, сохранив его себе, я могу авторизоваться с любого адреса, создавая сессию и авторизуясь, в не зависимости от того, как и откуда ранее я проходил аутентификацию?
Если так, то это немного упрощает задачу.
Да, все верно. Также можно срок действия токена не ограничивать, главное его использовать раз в 100 дней.
Да, все верно. Также можно срок действия токена не ограничивать, главное его использовать раз в 100 дней.
Спасибо! Все понятно теперь.
Объясните пожалуйста в чем преимущества новой авторизации? Чем была плоха старая?
Вроде бы только увеличивалось кол-во запросов.
Раньше было так:
http://hst-api.wialon.com/wialon/ajax.html?svc=core/login¶ms={"user":"****","password":"****"}
В скором времени:
http://hosting.wialon.com/oauth.html?pa … type=0x100
в ответе получаем токен и далее
http://hst-api.wialon.com/wialon/ajax.html?svc=token/login¶ms={"token":"****"}
Далее выполняем любой другой запрос.
Авторизация при помощи токенов - более современный и защищенный механизм.
Не нужно будет где-то хранить критически важные аутентификационные данные (логин и пароль),
которые могут быть перехвачены злоумышленниками.
Ввод логина и пароля разрешён только на нашей форме, что исключает их кражу и использование
в недобросовестных целях.
Кроме того логин и пароль не будут храниться в cookies и localStorage, что также усложнит задачу злоумышленникам.
Токен же может быть создан с заведомо ограниченными правами и сроком действия. И даже если такой токен будет
перехвачен - его можно спокойно удалить.
Конечно всех задач безопасности токены не решают, но делают серьёзный шаг в сторону защиты.
Ну и большинство известных сайтов, сервисов, социальных сетей и т.д., где присутствует авторизация, уже используют механизм oAuth.
Авторизация при помощи токенов - более современный и защищенный механизм.
Не нужно будет где-то хранить критически важные аутентификационные данные (логин и пароль),
которые могут быть перехвачены злоумышленниками.
Ввод логина и пароля разрешён только на нашей форме, что исключает их кражу и использование
в недобросовестных целях.
Кроме того логин и пароль не будут храниться в cookies и localStorage, что также усложнит задачу злоумышленникам.
Токен же может быть создан с заведомо ограниченными правами и сроком действия. И даже если такой токен будет
перехвачен - его можно спокойно удалить.
Конечно всех задач безопасности токены не решают, но делают серьёзный шаг в сторону защиты.
Ну и большинство известных сайтов, сервисов, социальных сетей и т.д., где присутствует авторизация, уже используют механизм oAuth.
Спасибо за ответ. Но хотелось бы знать, можно ли, не показывая вашу форму с вводом логина и пароля пользователю, получить токен и далее использовать его в запросах?
Теперь, не показывая форму, токен не получить, также как и не залогиниться без неё.
Но через форму можно один раз сгенерировать т.н. бесконечный токен и использовать в дальнейшем.
Теперь, не показывая форму, токен не получить, также как и не залогиниться без неё.
Но через форму можно один раз сгенерировать т.н. бесконечный токен и использовать в дальнейшем.
Утверждение не верно. 15 строчек кода и золотой токен в кармане.
Ещё раз спрашиваю, если я могу авторизоваться без формы и получить токен. Могу ли я его в дальнейшем использовать? От вас будут какие-либо претензии?
Не можете. Эти строчки кода известны, но работают они только сейчас.
В ближайшее время эта возможность будет прикрыта, т.к. нарушает основопологающие принципы oAuth.
Токен можно получать только через нашу стандартную форму. Все остальные обходные пути не будут работать
и будут приравниваться к несанкционированному доступу.
Не можете. Эти строчки кода известны, но работают они только сейчас.
В ближайшее время эта возможность будет прикрыта, т.к. нарушает основопологающие принципы oAuth.
Токен можно получать только через нашу стандартную форму. Все остальные обходные пути не будут работать
и будут приравниваться к несанкционированному доступу.
А какие основопологающие принципы oAuth нарушены?
Ок. Раз известны строчки кода. Тогда поделюсь с сообществом.
#!/usr/bin/python2.7
import urllib
import urllib2
import re
url = "http://hosting.wialon.com/oauth.html"
values = {"client_id": "wialon", "redirect_uri":"http://hosting.wialon.com/login.html", "access_type":"0x100", "activation_time":"0", "duration":"0", "flags":"0", "login":"", "passw":""}
data = urllib.urlencode(values)
req = urllib2.Request(url, data)
response = urllib2.urlopen(req)
#the_page = response.read()
redirect_url = response.geturl()
#print the_page
print "REDIRECT_URL: " + redirect_url
# 'http://hosting.wialon.com/login.html?access_token=b5f4f271c8953ae8778b24b99202e2003DCE1715AA1077E514E57D4A876394EB867B764F&svc_error=0'
pattern = re.compile(".*" + "access_token=([0-9a-fA-F]{72})" + "\&" + "svc_error=(\\d)" + ".*")
parser = pattern.match(redirect_url)
token = parser.group(1)
svc_error = parser.group(2)
print "TOKEN: " + token
print "SVC_ERROR: " + svc_errorСтучаться на oauth.html напрямую с логином и паролем - это по сути уязвимость,
которую мы на первом этапе внедрения токенов не учитывали. Сама по себе задача по переходу на oAuth
совсем не простая и быстрая и потребовала множество правок, доработок и т.д.
На первом этапе мы сконцентрировались на корректной поддержке токенов и внедрению на всех сайтах.
Сейчас, когда все основные проблемы по работе с токенами решены, можно переключиться на
закрытие уязвимостей. Конкретно эту уже исправили и в ближайшем обновлении так токен нельзя будет получить.
Про существование этой мы знали, но откладывали правки.
Что касается Вашего кода - особым достижением я бы это не назвал.
Но в любом случае спасибо за то, что подтолкнули нас исправить эту уязвимость сейчас)