- Авторизация через Google в Android и проверка токена на сервере
- Небольшая подготовка
- Добавляем действие на кнопку
- Необходимые области доступа
- Регистрация нашего приложения.
- Код получения токена
- Проверяем токен на сервере. (PHP)
- Logcat
- Быстрое отключение журналирования
- LogCat на устройстве
- XDA Basics: How to take logs on Android
- Kernel panic logs
- Driver messages
- System logs
- Android apps for collecting logs
- Logcat Extreme
- Android Login – Аутентификация учетной записи и проверка подлинности вручную
- Сроки.
- Резюме из методов addAccount и getAuthToken
- Исходные материалы благодаря
Авторизация через Google в Android и проверка токена на сервере
Недавно мне захотелось создать личный проект на андроиде, и основной вопрос был такой: как однозначно идентифицировать пользователя заставляя его делать как можно меньше телодвижений? Конечно же это аккаунт Google. Я пытался пробовать множество примеров в сети — однако API несколько раз обновилось за время своего существования, многие методы не работали, мои вопросы в Google+ по этому поводу либо были вообще никак не восприняты окружением, либо были вроде «Никогда такое не делал».
В этой статье я постараюсь как можно более просто для новичков (вроде меня) описать мой метод авторизации в Google на андроид, получения токена и проверке этого самого токена на сервере.
Небольшая подготовка
Для начала — у вас должны быть установлены Google Play Services в SDK. После их установки можно будет импортировать все необходимые библиотеки. Статья пишется с расчетом на Android Studio — он сам подсказывает, что необходимо импортировать.
У вас должно быть создано активити с кнопкой.
Чтобы было привычнее пользователю можете создать стандартную кнопку Google+ Sing-In
Выглядеть она будет вот так:
Просто добавьте в ваш Layout:
Добавляем действие на кнопку
Пишем в нашем активити:
Собственно присвоим кнопке действие — вызов интенда выбора аккаунта. Если вы работаете в Android Studio он сам вам подскажет, какие библиотеки нужно импортировать, так что это подробно тут я расписывать не буду.
startActivityForResult(intent, 123); — задает код с которым произойдет возврат. 123 это код возврата, он может быть каким угодно. Это необходимо, когда вы делаете несколько интендов, и вам надо обработать их по разному.
Необходимые области доступа
Обьявите эти переменные в классе. Это необходимые нам области доступа. Первый написано в google: «Позволяет определить аутентифицированного пользователя. Для этого при вызове API необходимо указать me вместо идентификатора пользователя Google+. » Второе разрешение нам необходимо для получения личных данных пользователя (Имя, Фамилия, адрес G+ страницы, аватар), и последнее для получения E-mail. Я посчитал это важным, ведь это вполне неизменный идентификатор для записи в бд.
Регистрация нашего приложения.
Изначально забыл этот пункт — исправляюсь.
Нам необходимо зайти на code.google.com/apis/console создать там проект, зайти в Credentials и создать новый Client ID для OAuth выбрав пункт Installed Application -> Android. Там нам необходимо ввести название нашего пакета и SHA1 сумму нашего ключа.
С этим у меня на самом деле было много проблем решил достаточно костыльным способом.
Нашел debug.keystore в %USERPROFILE%\.android\debug.keystore поместил в папку с проектом и прописал в build.grandle:
После чего нам нужно выполнить команду:
keytool -exportcert -alias androiddebugkey -keystore
/.android/debug.keystore -v -list
Сам keytool можно найти в SDK. Из вывода копируем SHA1 в нужное поле.
Как я понимаю метод временный, и для нормальной работы надо создать нормальный ключ. Но для тестирования этого достаточно.
Код получения токена
Где 123 — ваш код, который вы указали ранее, где AcrivityName — название вашего актитивити. Грубо говоря — мы скармливаем функции получения токена необходимые разрешения и имя аккаунта. И заметьте — это все происходит в фоновом режиме, после чего полученный токен передается в написанную мною функцию reg. Она уже отправляет токен и все необходимые данные на сервер.
Так как разрабатываю недавно, с исключениями пока что беда, если есть предложение — напишите в личку или в комментарии.
Проверяем токен на сервере. (PHP)
Хочу обратить внимание, полученный нами токен имеет тип Online. И действует он лишь 10 минут. Для получения offline токена (чтобы дольше работать с ним с сервера) обратитесь к этой инструкции developers.google.com/accounts/docs/CrossClientAuth
Собственно скармливаем токен в googleapis и забираем полученный JSON ответ.
Источник
Logcat
В Android SDK входит набор инструментов, предназначенных для отладки. Самый важный инструмент при отладке — это LogCat (очень красивое название, которое можно перевести как Логичный Кот). Он отображает сообщения логов (журнал логов), рассылаемые при помощи различных методов.
Рассмотрим на примере. Очень часто программисту нужно вывести куда-то промежуточные результаты, чтобы понять, почему программа не работает. Особо хитрые временно размещают на экране текстовую метку и выводят туда сообщение при помощи метода textView.setText(«Здесь был Васька»). Но есть способ лучше. В Android есть специальный класс android.util.Log для подобных случаев.
Класс android.util.Log позволяет разбивать сообщения по категориям в зависимости от важности. Для разбивки по категориям используются специальные методы, которые легко запомнить по первым буквам, указывающие на категорию:
- Log.e() — ошибки (error)
- Log.w() — предупреждения (warning)
- Log.i() — информация (info)
- Log.d() — отладка (degub)
- Log.v() — подробности (verbose)
- Log.wtf() — очень серьёзная ошибка! (What a Terrible Failure!, работает начиная с Android 2.2)
- Log.meow() — когда жрать дадут? (MEOW!) Недокументированный метод, используйте на свой страх и риск. Работает не на всех устройствах
В первом параметре метода используется строка, называемая тегом. Обычно принято объявлять глобальную статическую строковую переменную TAG в начале кода:
Некоторые в сложных проектах используют следующий вариант, чтобы понимать, в каком классе происходит вызов:
Далее уже в любом месте вашей программы вы вызываете нужный метод журналирования с этим тегом:
Также используется в исключениях:
Пользователи не видят этот журнал. Но, вы, как разработчик, можете увидеть его через программу LogCat, доступный в Android Studio.
Полный вид сообщения выглядит следующим образом.
03-09 20:44:14.460 3851-3879 / ru.alexanderklimov.cat I/OpenGLRenderer : Initialized EGL, version 1.4
- 03-09 20:44:14.460 Date/Time
- 3851-3879 Process & Thread IDs
- ru.alexanderklimov.cat Package name
- I/OpenGLRenderer Tag
- Initialized EGL, version 1.4 Message
Подобные длинные сообщения не всегда удобны для чтения. Вы можете убрать ненужные элементы. Для этого выберите значок LogCat Header в виде шестерёнки и уберите флажки у опций.
В LogCat вы можете отфильтровать сообщение по заданному типу, чтобы видеть на экране только свои сообщения. Для этого выберите нужный тип тега из выпадающего списка Verbose.
Типы сообщений можно раскрасить разными цветами через настройки File | Settings | Editor | Colors Scheme | Android Logcat.
Для отслеживания сообщений с заданным текстом введите в поле поиска нужную строку и нажмите Enter.
Также активно используйте варианты из других выпадающих списков. Например, выбирайте свой пакет из второй колонки, а в последней выбирайте Show only selected application. Для более точной настройки используйте Edit Fiter Configuration.
По умолчанию, окно LogCat выводится в нижней части студии. При желании, можно выбрать другие варианты через значок настроек окна.
LogCat также можно запустить из командной строки:
Параметры командной строки смотрите в документации.
Быстрое отключение журналирования
Настоятельно рекомендуется удалять все вызовы LogCat в готовых приложениях. Если проект очень большой и вызовы журналирования разбросаны по всем местам кода, то ручное удаление (или комментирование) становится утомительным занятием. Многие разработчики используют следующую хитрость — создают обёртку вокруг вызова методов LogCat.
Теперь остаётся только присвоить нужное значение переменной isDebug перед созданием готового apk-файла для распространения.
Способ устарел. В 17-й версии Android Build Tools появился класс BuildConfig, содержащий статическое поле DEBUG. Можно проверить следующим образом:
Способ для продвинутых — например, требуется релиз с выводом в лог, или наоборот — debug с выключенным выводом. В этом случае можно создать собственный параметр и добавить его в секцию buildType gradle-файла:
В этом случае конфигурация releaseWithLog будет являться релизной сборкой с ведением логов. Естественно, в коде слегка поменяется проверка:
LogCat на устройстве
Попался в сети пример для просмотра сообщений LogCat на устройстве. С примером не разбирался, оставлю здесь на память.
Источник
XDA Basics: How to take logs on Android
Logs are very useful when a developer is diagnosing an error with a piece of software. So, as a user, when you complain to a developer about a problem with their Android app or an aftermarket firmware (custom ROM), they’ll ask you to submit a log to help them troubleshoot the issue. Android includes a number of logs that deal with different parts of the firmware, and there are a number of ways to collect those logs. In this guide, we’ll talk about the various common logs and how you can collect them on Android for bug reports.
Before we start, you should set up Android Debug Bridge on your computer as you might need ADB access for some of these logs. We have a great guide on how to set up ADB on any computer.
Kernel panic logs
Kernel panic logs are useful to figure out what happened during an unsuccessful boot. If you’re trying to run a custom ROM but your phone is stuck at the boot loop, you can collect kernel panic logs to help the ROM developer find out what went wrong.
A majority of Android manufacturers use upstream вЂpstore’ and вЂramoops’ drivers to store kernel logs after a panic. Ramoops writes its logs to the RAM before the system crashes. With root access, these logs can be retrieved from:
The file name could be slightly different but it’ll be in the pstore directory. You can get it using ADB pull or any other way you want. For example:
adb pull /sys/fs/pstore/console-ramoops C:\Users\Gaurav\Desktop\filename
Driver messages
The log from the driver messages buffer can be used to diagnose issues with system drivers and why something isn’t working. On Android, you can use the ‘dmesg’ output to get these logs. You’ll need root access to get these logs though. Use the following ADB command to export the complete log.
System logs
System logs are useful when something in the system throws an error. Android allows collecting system logs using Logcat. Log messages can be viewed in a Logcat window in Android Studio, or you can use the command line tool to pull them.
Several Android apps are also available in the Google Play store that allow easy access to these tools. We’ll talk about these apps later in this article. Moreover, several custom ROMs come with options in the Developers settings to collect the system logs.
To collect logs using ADB, use the following command. This command will export a continuous log, so use Ctrl + C to stop it.
You can use the -d parameter to export the complete log in one go.
If you want, you can also view or save the radio buffer using the following command.
If your device is rooted, you can use the Terminal app on the device itself to collect logs. To save a log using Terminal on your phone, type the following command so the log will be saved on your phone.
Android apps for collecting logs
Logcat Extreme
Logcat Extreme can help you read the logcat and dmesg outputs as well as record logs. It requires root access to show logs properly.
Источник
Android Login – Аутентификация учетной записи и проверка подлинности вручную
Я собираюсь внедрить логин вместе с аутентификацией пользователя в своем приложении.
Моя первая идея заключалась в том, чтобы сделать это вручную, зарегистрировать имя пользователя и пароль с сервером, получить токен аутентификации, сохранить его и использовать в последующих запросах.
После поиска в Google, я понял, что правильным способом сделать это на Android было использование Account Authenticator. Я видел несколько примеров его реализации, но я не понимаю, как это сделать так? Это потому, что я могу хранить несколько учетных записей? Это из-за проблем синхронизации? Я был бы признателен, если бы кто-нибудь мог мне это объяснить. Вероятно, это заставило бы меня лучше понять код для него и почему он делает то, что он есть.
Я могу хранить несколько учетных записей?
Да. Посмотрите, как это делают Google или Facebook .
Да, вам нужна учетная запись для использования механизма синхронизации, такого как SyncAdapter
Почему вы должны использовать AccountAuthenticator ?
Поддержка механизма синхронизации фона, такого как SyncAdapter ;
Стандартный способ аутентификации пользователей;
Поддержка различных токенов;
Совместное использование аккаунта с разными привилегиями
Что тебе нужно сделать?
1). Создать Authenticator ;
2). Создать Activity для входа пользователя;
3). Создайте Service для связи с учетной записью.
Сроки.
AccountManager – управляет учетной записью на устройстве. Запросите токены, которые вы должны использовать AccountManager .
AbstractAccountAuthenticator – компонент для работы с типами учетных записей. Он содержит всю логику работы с учетной записью (авторизация, права доступа и т. Д.). One AbstractAccountAuthenticator может использоваться различными приложениями (например, для учетной записи Google для Gmail, календаря, диска и т. Д.).
AccountAuthenticatorActivity – базовая Activity , для авторизации / создания учетной записи. AccountManager вызывает эту учетную запись, если необходимо идентифицировать учетную запись (токен не существует или истек)
Как все это работает? Посмотрите на изображение ниже:
1). Создать Authenticator ;
Вам необходимо расширить AbstractAccountAuthenticator и переопределить 7 методов:
- Bundle editProperties(AccountAuthenticatorResponse response, String accountType) ссылка
- Bundle addAccount(AccountAuthenticatorResponse response, String accountType, String authTokenType, String[] requiredFeatures, Bundle options) ссылка
- Bundle confirmCredentials(AccountAuthenticatorResponse response, Account account, Bundle options) link
- Bundle getAuthToken(AccountAuthenticatorResponse response, Account account, String authTokenType, Bundle options)
- String getAuthTokenLabel(String authTokenType) ссылка
- Bundle updateCredentials(AccountAuthenticatorResponse response, Account account, String authTokenType, Bundle options)
- Bundle hasFeatures(AccountAuthenticatorResponse response, Account account, String[] features) link
Итак, вам нужно увидеть только 2 метода: addAccount , getAuthToken .
В addAccount я добавил некоторые параметры конфигурации, которые будут использоваться моей addAccount для входа пользователя. Главное здесь – intent.putExtra(Config.ARG_ACCOUNT_TYPE, accountType); – здесь вы должны указать тип учетной записи. Другие манипуляции не нужны.
В getAuthToken – Прочитайте комментарии, пожалуйста . Я скопировал этот метод из UdinicAuthenticator.java
Кроме того, вам понадобятся следующие разрешения в вашем AndroidManifest.xml:
Резюме из методов addAccount и getAuthToken
Попробуйте получить токен, если токен имеет результат возврата, иначе вы увидите « Activity для авторизации»
2). Создать Activity для входа пользователя;
Краткое описание: Создайте форму с UserId и Password. Используя данные UserId & Password, вы получите токен аутентификации с сервера, а затем выполните следующий шаг:
3). Создайте Service для связи с учетной записью.
Не забудьте добавить эту строку в AndroidManifest.xml в Service :
А также в res/xml добавить файл authenticator.xml :
Это все. Вы можете использовать свой AccountAuthenticator .
Исходные материалы благодаря
Даниэль Сердюков (весь текст переведен из его статьи (кроме моих небольших дополнений) «Синхронизация в приложениях для Android. Часть 1» только на русском языке. Ссылка: http://habrahabr.ru/company/e-Legion/blog/206210/ )
AccountManager хорош по следующим причинам:
- Во-первых, хранить несколько имен учетных записей с различными уровнями доступа к функциям приложения под одним типом учетной записи. Например, в приложении для потоковой передачи видео могут быть два имени учетной записи: один с демо-доступом к ограниченному числу видео, а другой с полносетевым доступом ко всем видео. Однако это не основная причина использования Accounts , так как вы можете легко управлять этим в своем приложении без необходимости в этой причудливой учетной Accounts ….
- Другим преимуществом использования Accounts является избавление от традиционной авторизации с именем пользователя и паролем каждый раз, когда пользователь запрашивает авторизованную функцию, поскольку проверка подлинности происходит в фоновом режиме, и пользователю предлагается ввести пароль только в определенных условиях, Который я получу к нему позже.
- Использование функции Accounts в android также устраняет необходимость в определении собственного типа учетной записи. Вероятно, вы сталкивались с приложениями, использующими учетные записи Google, для авторизации, что избавляет вас от необходимости создавать новую учетную запись и запоминать ее учетные данные для пользователя.
- Accounts могут быть добавлены независимо через Настройки → Учетные записи
- Межплатформенную авторизацию пользователей можно легко управлять с помощью Accounts . Например, клиент может одновременно получить доступ к защищенным материалам в своем устройстве android для Android и без необходимости повторного входа в систему.
- С точки зрения безопасности использование одного и того же пароля в каждом запросе на сервер допускает возможность подслушивания в незащищенных соединениях. Шифрование пароля здесь недостаточно, чтобы предотвратить кражу паролей.
- Наконец, важной причиной использования функции Accounts в android является разделение двух сторон, вовлеченных в любой бизнес, зависящий от Accounts , так называемый аутентификатор и владелец ресурсов, без ущерба для учетных данных клиента (пользователя). Термины могут показаться довольно расплывчатыми, но не сдавайтесь, пока вы не прочитаете следующий параграф … 😉
Позвольте мне подробно остановиться на примере приложения для потоковой передачи видео. Компания A является владельцем видеопотока в контракте с Компанией B, чтобы предоставить своим определенным участникам услуги премиум-потоковой передачи. Компания B использует метод имени пользователя и пароля для распознавания его пользователя. Чтобы компания A признала премиум-членов B, одним из способов было бы получить их список из B и использовать аналогичный механизм совпадения имени пользователя и пароля. Таким образом, аутентификатор и владелец ресурсов являются одинаковыми (компания A). Помимо обязательности пользователей помнить второй пароль, очень вероятно, что они установили тот же пароль, что и профиль их компании B для использования услуг от A. Это, очевидно, не является благоприятным.
Чтобы устранить вышеупомянутые недостатки, OAuth был представлен. В качестве открытого стандарта для авторизации в приведенном выше примере OAuth требует, чтобы авторизация выполнялась компанией B (аутентификатором) путем выдачи некоторого токена под названием Access Token для правомочных пользователей (третьего лица), а затем предоставления Компании A (владельцу ресурса) Токен. Таким образом, никакой токен не означает права на участие.
Я подробно рассказал об этом и AccountManager другом в AccountManager на моем сайте здесь
В настройках Android вы учитываете свой тип учетной записи, и оттуда вы можете добавить учетную запись. AccountManager также является центральным местом для хранения учетных данных, поэтому вы регистрируетесь только один раз для каждого поставщика. Если вы загружаете другое приложение Google или получаете доступ к приложению несколько раз, вы вводите только учетные данные один раз
Источник