Всем привет, пишу игру для ВК. FLASH+JAVA+MySQL.
Чтобы залогинится на сервер любой игры, всегда нужно вводить логин и пароль.
Но в приложениях в ВК никаких паролей вводить не нужно.
Возник следующий вопрос:
Какими средствами API ВК можно добиться такой авторизации?
Что должно служить паролем , если логин это ID-юзера?
Как вообще можно защититься от несанкционированных запросов серверу?
Для чего нужен "access_token" и как с ним работать?
Начал изучать данную тему, документацию по API прочитал, но толком вкурить не могу...
Если не сложно можете на пальцах объяснить или подсказать где можно это все изучить.
Авторизация пользователей
Re: Авторизация пользователей
auth_key...Что должно служить паролем , если логин это ID-юзера?
access_token для отправки запросов(но по-сути он не нужен, если не отправлять запросы с сервера...).Для чего нужен "access_token" и как с ним работать?
ждать после подключения, например, 5 секунд... если чел не авторизовался - выкидывать и все... а без авторизации вообще все, желательно, игнорировать..Как вообще можно защититься от несанкционированных запросов серверу?
апи здесь не причем.. на сокетах(ведь я так понял) можно передать серверу его айди и auth_key, а потом проверить:Какими средствами API ВК можно добиться такой авторизации?
Код: Выделить всё
// классы для md5import java.security.MessageDigest;import java.security.NoSuchAlgorithmException;import java.math.BigInteger;....if( md5(Long.toString(айди_приложения) + '_' + Long.toString(айди_юзера) + '_' + секретный_ключ).equals(аутз_кей) ) { // все ок... } else //обманывает... ...// функция шифрования md5 public static String md5(String s) { String hash; try { MessageDigest m = MessageDigest.getInstance("MD5"); m.update(s.getBytes("UTF8"), 0, s.length()); hash = new BigInteger(1, m.digest()).toString(16); } catch (Exception e) { return ""; } if(hash.length() == 31) hash = "0" + hash; return hash; }
Re: Авторизация пользователей
Эмм...спасибо, более менее понятно.
Да на сокетах.
Я вот подумал:
Клиент у нас ничего не решает, только отрисовка событий на сервере,
тогда клиент отправляет серверу просто запрос например - "idUser+commandMoveTo10" (без всякого шифрования).
Сервер в свою очередь знает текущее состояние юзера с idUser, понимает можно ли ему выполнить commandMoveTo10,
и отправляет уже клиенту можно либо нельзя. После чего клиент либо рисует, либо нет.
Какие при этом могут возникнуть проблемы, кроме большой нагрузки на сервер?
Если да то оно как я понимаю никогда не меняться и для каждого приложения установленного у пользователя оно разное, или как?
.......
Все кажись разобрался:
Вычисляется по формуле:
auth_key = md5(api_id + ‘_’ + viewer_id + ‘_’ + api_secret)
Так как у нас поля "api_id, viewer_id, api_secret" всегда статичны и только мы знаем api_secret, то мы просто генерируем для себя auth_key, пароль для каждого пользователя. И уже его проверяем при следующем входе.
Правильно понял?
......
Что мешает злоумышленнику подложить чужой ID и от его имени что либо сделать?
Может уже не по теме:
От так называемых "ботов" нас это никак не защитит?
Да на сокетах.
Я вот подумал:
Клиент у нас ничего не решает, только отрисовка событий на сервере,
тогда клиент отправляет серверу просто запрос например - "idUser+commandMoveTo10" (без всякого шифрования).
Сервер в свою очередь знает текущее состояние юзера с idUser, понимает можно ли ему выполнить commandMoveTo10,
и отправляет уже клиенту можно либо нельзя. После чего клиент либо рисует, либо нет.
Какие при этом могут возникнуть проблемы, кроме большой нагрузки на сервер?
Это поле из "flashVars"?auth_key
Если да то оно как я понимаю никогда не меняться и для каждого приложения установленного у пользователя оно разное, или как?
.......
Все кажись разобрался:
Вычисляется по формуле:
auth_key = md5(api_id + ‘_’ + viewer_id + ‘_’ + api_secret)
Так как у нас поля "api_id, viewer_id, api_secret" всегда статичны и только мы знаем api_secret, то мы просто генерируем для себя auth_key, пароль для каждого пользователя. И уже его проверяем при следующем входе.
Правильно понял?
......
Что мешает злоумышленнику подложить чужой ID и от его имени что либо сделать?
Может уже не по теме:
От так называемых "ботов" нас это никак не защитит?
Re: Авторизация пользователей
логика правильна в принципе, но не совсем... если это шутер то нужно так:Клиент у нас ничего не решает, только отрисовка событий на сервере,
тогда клиент отправляет серверу просто запрос например - "idUser+commandMoveTo10" (без всякого шифрования).
Сервер в свою очередь знает текущее состояние юзера с idUser, понимает можно ли ему выполнить commandMoveTo10,
и отправляет уже клиенту можно либо нельзя. После чего клиент либо рисует, либо нет.
игрок сдвинулся вправо на 20м, мы отправляем на сервер и не дожидаясь ответа движемся на основании текущей информации, когда пришел ответ - если все правильно сделали, то не трогаем, если нет - то корректируем и все...(интерполяция, экстраполяция кароче....) хоть такой способ сложнее, но все шутеры именно им пользуются, иначе создастся тупое впечатления замедленной реакции...
если это онлайн-рисовалка или шахматы и тп. то в этом нет смысла... тут пинг в 200-300мс большой роли не играет...
никаких. разве что читерство, потому нужно все проверять(в шутерах проверяется по упрощенным формулам, допуская в % ошибку...)Какие при этом могут возникнуть проблемы, кроме большой нагрузки на сервер?
нет, не правильно) поле auth_key передается с флешварс или через $_GET для php и его не нужно генерировать... при каждом заходе в приложение он передается и мы может спокойно ним пользоваться...Это поле из "flashVars"?
Если да то оно как я понимаю никогда не меняться и для каждого приложения установленного у пользователя оно разное, или как?
.......
Все кажись разобрался:
Вычисляется по формуле:
auth_key = md5(api_id + ‘_’ + viewer_id + ‘_’ + api_secret)
Так как у нас поля "api_id, viewer_id, api_secret" всегда статичны и только мы знаем api_secret, то мы просто генерируем для себя auth_key, пароль для каждого пользователя. И уже его проверяем при следующем входе.
Правильно понял?
проверка auth_key'а(мы на сервере генерируем правильный, в зависимости от айди, а потом сверяем с присланным), т.к. злоумышленник его знать не может(потому-что не знает секретного ключа, а значит он не может сгенерировать его), кроме случаев кражи auth_key'а....Что мешает злоумышленнику подложить чужой ID и от его имени что либо сделать?
никак. от ботов защита уже делается самостоятельно, например отсылая необычные пакеты, используя кейлогер(писать нажатия клавиш и их проверять), проверять на % тупых действий и много других способов...Может уже не по теме:
От так называемых "ботов" нас это никак не защитит?
upd: почитай мой урок http://flapps.ru/forum/topic7181.html, найдешь много нового=) так именно есть и авторизация и проверка аутз_кея и отсылка и прием сообщений....