Android studio авторизация через api

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

Мы сделаем приложение, при запуске которого нужно будет выполнить вход с помощью ввода логина и пароля — если данные введены верно мы попадаем на другой экран, если не правильно, то видим сообщение об ошибке.

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

Создаем новый проект, выбираем Blank Activity. Для начала создадим пользовательский интерфейс для приложения. Он будет состоять из полей ввода логина/пароля и кнопки для совершения входа. Открываем файл activity_main.xml и добавляем туда следующее:

Мы получили вот такой вид пользовательского интерфейса:

Сразу разберемся со вторым экраном, на который будет совершаться переход в случае успешного ввода логина и пароля. Создаем новый класс по имени Second.java:

И соответствующий ему layout файл по имени second_activity.xml:

Ну а теперь переходим к файлу основному MainActivity.java. Основной процесс будет происходить в методе обработки нажатия кнопки «Войти». В нем мы сравниваем введенные логин и пароль со словом admin и в зависимости от их совпадения или не совпадения настраиваем дальнейшие действия. Если введены логин и пароль admin, то высвечивается Toast сообщение об успехе входа и выполняется переход на второй экран с помощью Intent. Если данные введены не верно, то высвечивается сообщение с ошибкой, а после 3 неудачных попыток появляется надпись, что количество попыток исчерпано, а кнопка «Войти» становится неактивной. Итак, чтобы реализовать сказанное, открываем файл MainActivity.java и добавляем в него следующий код:

Кстати, не забудьте добавить вторую activity в файл манифеста AndroidManifest.xml:

Проверяем работоспособность своего творения:

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

Источник

Аутентификация через OAuth2

Чтобы получить доступ к некоторым онлайн-сервисам, пользователям нужно пройти аутентификацию. Обычно он вводит свой логин и пароль в браузере. Если вы создаёте своё приложение, которое будет подключаться к такому сервису, то не только пользователь должен пройти аутентификацию для доступа к сервису в вашем приложении, но и приложение должно быть авторизовано для выполнения действий от имени пользователя.

На данный момент стандартным протоколом для аутентификация является OAuth2 (Open Authorization). OAuth2 обеспечивает единственное значение, называемое токен авторизации (Auth Token), который представляет как пользователя, так и авторизованное приложения, которое будет действовать от имени пользователя.

Протокол используют Twitter, Google, Flickr, Digg, Yahoo и многие другие сервисы.

Необходимо понимать разницу между терминами аутентификация (authentication) и авторизация (authorization).

Аутентификация — вы посещаете режимное предприятие и показываете своё удостоверение. Охранник смотрит и принимает решение: удостоверение настоящее? печать на месте? фотка совпадает? Опытный охранник может узнать вас в лицо и пропустить и так. Аутентификация может быть простой, а может быть и сложной.

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

Авторизация наступает после успешной аутентификации. Даже если вы показали настоящее удостоверение, у вас может быть запрет на посещение отдельных этажей, комнат, серверной и т.д. Или вы не можете пройти в здание по выходным.

Авторизация определяет ограничения на доступные действия. Используя OAuth, мы задаём границы доступа пользователя. Например, пользователь может читать личные сообщения, а босс может просматривать переписку любого сотрудника. Причём, открытая аутентификация означает, что мы сами не занимаемся проверкой логина и пароля, а только получаем готовую информацию. Иными словами, организация заключила договор с охранным предприятием, который и поставляет охранников и занимается системой охраны.

Использование OAuth2 подходит для:

Получения разрешения от пользователя для доступа к онлайн-службе с помощью своей учетной записи.
Аутентификация на онлайн-сервисе от имени пользователя.
Обработка ошибок аутентификации.

Чтобы начать использовать OAuth2, вы должны знать:

URL сервиса, к которому вы хотите получить доступ.
Рамки аутентификации (auth scope), которые являются строкой, определяющей конкретный тип доступа, запрашиваемый вашим приложением. Например, запрос доступа только для чтения к Google Tasks – это View your tasks, в то время как доступ для чтения и записи к Google Tasks – это Manage Your Tasks.
Идентификатор клиента (client id) и «секрет клиента» (client secret) – это строки, которые идентифицируют ваше приложение на сервисе. Вы должны получить эти строки непосредственно у владельца сервиса. Google имеет систему самообслуживания для получения идентификаторов клиента и секретов. Статья Getting Started with the Tasks API and OAuth 2.0 on Android объясняет, как использовать эту систему, чтобы получить эти значения для использования c Google Tasks API.

Запрос Auth Token

Теперь вы готовы запрашивать токен авторизации. Это многоступенчатый процесс.

Для получения токена авторизации необходимо сначала запросить права на использование ACCOUNT_MANAGER в манифесте. Не забываем про разрешение на интернет.

Имея необходимые полномочия, вы можете вызвать AccountManager.getAuthToken() для получения токена. Большинство методов AccountManager – асинхронные. Вам придётся реализовать её в виде серии обратных вызовов, например:

В этом примере класс OnTokenAcquired расширяет AccountManagerCallback. AccountManager вызывает run() в OnTokenAcquired с AccountManagerFuture, содержащим Bundle. Если вызов успешен, то токен будет внутри Bundle.

Вы можете получить токен из Bundle:

Если все пойдёт хорошо, то Bundle будет содержать допустимый токен в ключе KEY_AUTHTOKEN. Но не всегда все идёт так как запланированно.

Ваш первый запрос токена авторизации может завершиться неудачей по нескольким причинам:

Ошибка в устройстве или сети вызвала сбой AccountManager.
Пользователь решил не предоставлять вашему приложению доступ к аккаунту.
Сохраненных полномочий аккаунта не хватает для получения доступа к аккаунту.
Кэшированный токен авторизации истек.

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

Третий случай неудачи, имеющий недостаточные полномочия, передается через Bundle, который вы получаете в вашем AccountManagerCallback (OnTokenAcquired из предыдущего примера). Если Bundle включает Intent в ключе KEY_INTENT, то аутентификатор говорит вам, что ему необходимо прямое взаимодействие с пользователем, прежде чем он может дать вам действительный токен.

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

Обратите внимание, что пример использует startActivityForResult(), и вы можете перехватить результат Intent в методе onActivityResult() в вашей активности. Если вы не станете перехватывать результат ответа Intent аутентификатора, невозможно будет определить прошёл ли пользователь проверку подлинности или нет. Если результат RESULT_OK, то аутентификатор обновил сохранённые полномочия, чтобы они были достаточны для доступа который вы запросили, далее вы должны вызвать AccountManager.getAuthToken() снова и запросить новый токен аутентификации.

Последний случай, когда токен истёк, на самом деле не ошибка AccountManager. Единственный способ выяснить действительно ли токен истек – это связаться с сервером, что было бы расточительным и дорогим со стороны AccountManager постоянно выходить в интернет и проверять состояние всех своих токенов. Так что эта неудача может быть обнаружено только когда приложение пытается использовать токен аутентификации для доступа к веб сервису.

Подключение к онлайн-сервисам

Пример ниже показывает, как подключиться к серверу Google. Так как Google использует стандарт протокола OAuth2 для проверки подлинности запросов, методы, обсуждаемые здесь широко применимы. Имейте в виду, что каждый сервер отличается. Вам может понадобиться внести небольшие изменения в этот пример для учета вашей конкретной ситуации.

Google API требует предоставления четырех значений с каждым запросом: API key, client ID, client secret, и auth key. Первые три получаются на сайте Google API Console. Последнее значение вы получаете вызвав AccountManager.getAuthToken(). Вы передаете их на сервер Google в качестве части HTTP-запроса.

Если запрос возвращает HTTP-ошибку 401, то ваш токен был отклонен. Самая распространённая причина этого – истечение токена. Исправить это просто: вызовите AccountManager.invalidateAuthToken() и повторите запрос токена еще раз.

Так как истечение токена является обычным явлением и исправление этой ситуации достаточно легкое, многие приложения просто предполагают истечение токена ещё до того как станет известно об этом. Если обновление токена дешёвая операция для вашего сервера, вы можете вызывать AccountManager.invalidateAuthToken() перед первым вызовом AccountManager.getAuthToken() и избавить себя от необходимость запрашивать токен аутентификации два раза.

В будущем мы рассмотрим практические примеры для OAuth.

Источник

Use Android Studio to stub web API; simple JWT login as an example

When documenting API or stubbing end-points for web API, Apiary has been the go-to solution for a while. However, there are times when you need to returns results based on users input and then, we very quickly hit up against the limitations of Apiary.

While most developers are comfortable with using Tomcat, Apache and Nginx with a back-end language, there is some overhead to downloading the new tools and setting up a new environment. Luckily for Android developers, there is a better way.

It’s pretty easy to dismiss Android Studio as nothing more than an Android Development environment. Lets face it, as far as development environments for Android go, it’s great! However, remember that it built on top of Intellij IDEA which is a very powerful development environment and that Android Studio is also a development platform for the Google Cloud Platform. I touched upon this power of Android Studio once before when I talked about How to create a mobile game with backend API’s in 5 minutes.

Why would you stub or build your own web API?

Off the top of my head, I can think of 2 main reasons to stub or build your own web API end-points.

Just using a static stubbed web API end-point is not enough.
In my experience, mobile developers can move a lot faster on project that web API developers. The reason for this is often that web API developers have to wait for the infrastructure to be available or at least spend some time and effort setting it up.
You are tasked with creating the API as well as the app.
I don’t think this one requires much explanation or justification. It can happen.

Setup the app

Start by creating a new Activity in your existing app, or by creating a new Android app with a LoginActivity. Effectively, when you see the screen below, select LoginActivity.

After the activity is added to your project, the next step for me is to clean out the code and get rid of a lot of stuff that I don’t need. The end result is that LoginActivity looks like this:

Set-up the Web API

To set-up the web API, go to File > New > New Module.

When you see the screen above, select “Google Cloud Module” and click Next.

On the next screen, fill in all the details as you like, or you can leave the default options. The only thing you have to make sure to select is the “Module type”

The “Module type” contains three values, you need to pick one that suits your needs best.

You can find more information on each of the options at the links above. I’ve chosen to use “App Engine Java Servlet Module” because the code for the Servlets is very succinct and makes it easier to copy paste.

When you finish, the Servlet generated will look like this:

If you look for the file web.xml, you’ll see that MyServlet is mapped to /hello. You can change this if you like. For my needs, I’ve changed it to /login.

You also want to find index.html and update the following line (this step is optional, fixing this means we can use the index page to confirm our api is running):

Now select “backend” from the run menu and hit the run button.

You should see output as shown below in red. Don’t panic, nothing is wrong, the console is just outputting the log in red. I don’t know why.

If you now go to http://localhost:8080, you should see index.html.

Now, lets modify our Servlet so that it takes a username and password and returns a JWT token.

Setting up backend for JWT

First find build.gradle for the backend module and add a dependency on the JWT library we will use. You can use any library you want, just head over to http://jwt.io and select one.

I’ve chosen to use JJWT because it has a very complete implementation of JWT standards and I like it’s syntax more than Jose4J. However, different libraries are easier or harder to use and you should pick one that suits you best.

Start by adding JJWT to your back-end module.

The modify your Servlet to generate a JWT token when a username and password is provided. Do note, that we don’t really care if the username and password are correct at this point.

You can now use Postman to validate whether the API end-point works, you will get a token back if your username and passwords are correct or else, you’ll get an error.

You can head over to http://jwt.io and test your token on that site.

Already we can see a benefit over using a static stub. We can enforce our contracts for what should happen if the input is invalid and we can test/develop against it.

Update your app to handle the token

I’m going to use koush’s Ion library to handle networking. IMHO it’s the fastest way to implement networking and image handling in any app. Simply add the dependency (1 line) and start coding.

Add the dependency in your apps build.gradle file.

Then in your LoginActivity, in attemptLogin(), post the username and password to our API end-point. Just remember that on your phone or tablet, you can’t use localhost and should replace it with the TCP/IP address of your machine, or if you use the emulator, you can use 10.0.2.2; if you use Genymotion you can use 10.0.3.2.

We update the code in our LoginActivity.attemptLogin() method to make the login call.

We are now able to write code to not only handle a successful login, but also to handle error conditions.

Next steps

Javadoc

If you want to use this as your primary form of stubbing or building a web API, I would use the Javadoc standard to document your API.

Distributing your Web API

Anyone with Android Studio should be able to run your project without any grief. However, if you need to distribute your API to allow others to develop on their own computers, you can generate a war using a simple command:

This should generate a war file under / /build/libs

This war should work in a Tomcat or Jetty without any problems.

Stubbing a database

Some times, you need to be able to stub a database or even persist one for stubbing or API development purposes. My personal recommendation here would be to use HyperSQL Database (HSQLDB) (only in the development environment). While you can’t do anything too complex with HSQLDB, you can run it as an in-memory database or as a database back-end by filter persistence. This allows you to create a fresh database from scratch and load it with data that is reset every time you restart the server, or even persist the data on disk if you like.

Admittedly, if you are doing this, you’re no longer stubbing API fast. However, you are making a very powerful and useful stubbed endpoint. If the database isn’t too complex, moving your stubs to a MySQL back-end would be rather fast and simple. There are some benefits to use HSQLDB on Android as well, hopefully I’ll cover this in the future. Needless to say that if your back-end is ultimately going to be a NoSQL DB, this is not the best option.

You can also use something like Firebase, however, you’ll need to be on-line to use Firebase so, off-line development is not possible. However, you get some other nice features like data being pushed when it changes. With Firebase, each developer can use their own account in development or share an account and developers can progammatically reset the state of the database or persist it. The downside of using Firebase is that the code doesn’t port too well, if you want to switch to a SQL db.

Finally

Please check out some of my articles on Medium. And, feel free to follow me on Google+, Twitter or LinkedIn.

Источник

Android studio авторизация через api