Ответ 1

Хорошо, есть что ответить. Но короткий ответ просто держите вещи простыми и аутентифицируемыми, как и обычное веб-приложение.

В обычном веб-приложении:

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

В мобильном приложении:

• В мобильном приложении вы будете делать то же самое с помощью ajax-запросов (используя $http в случае angular).
• После завершения проверки подлинности на сервере отправьте ответ обратно в приложение (например, json/xml), указав на переднюю часть результат аутентификации.

Каков стандартный подход?

• Я не уверен в стандарте, но это, пожалуй, самый простой подход. Стандарты всегда меняются, потому что всегда есть лучший способ сделать это. Так что до тех пор, пока он выполняет задание, пойдите для этого, улучшите его позже.

Должен ли я использовать Node.JS в качестве прокси-сервера для базы данных?

• Я не использовал большую часть nodeJs, поэтому я не знаю, что вы на самом деле имеете в виду. Но если это помогает знать - я использую php на сервере, который получает запрос ajax, обрабатывает аутентификацию с помощью базы данных mysql и возвращает ответ на мобильное приложение.

Неужели я все это делаю неправильно?

• Я не видел вашу начальную настройку. Что касается аутентификации, когда вы меняете состояния приложения, вы можете использовать localStorage для хранения информации о пользователе после успешного входа в систему. При выходе из системы очистите localStorage. Итак, все, что вам нужно сделать, это проверить, существует ли значение в localStorage для подтверждения входа пользователя.

Каковы мои потенциальные дорожные блоки?

• Я предлагаю вам начать делать свое приложение, и вы скоро это узнаете. В целом ионная + кордова делает вещи довольно простыми и устраняет большинство препятствий для разработки приложений.

Как работает CORS с гибридными приложениями?

• Кордова разрешает запрос по перекрестному домену по умолчанию, поэтому у вас не возникнет проблем с перекрестными доменами, и вы можете напрямую получить доступ к серверу для проверки подлинности.

Все, что мне не хватает?

• IonicFramework - это только интерфейс HTML5 с интерфейсом. Только он не может сделать вас мобильным приложением. Он просто даст вам хороший интерфейс для работы. IonicFramework предоставляет вам несколько полезных функций javascript, которые он реализует с помощью angular. Таким образом, чтобы получить максимальную отдачу от ионных, вы должны обладать навыками angularJs. Обучение angular стоит того, чтобы идти на это.

• Фактическое приложение составлено Кордовой. Кордова принимает ваши обычные файлы html/css/javascript и упаковывает их в Android-приложение orroid или iphone ipa, чтобы они могли быть установлены на соответствующие ОС как собственные приложения.

• Кордова - это то, что позволит вам получить доступ к основным функциям телефона, таким как камера, галерея, контакты и др.

Обновлено 3 июня 2015 г.

Аутентификация на основе токенов. Я считаю, что это альтернатива. Это более чистый и безопасный способ обработки аутентификации, который теперь легко доступен.

Для получения дополнительной информации ознакомьтесь со следующими ссылками:

• Angular jwt (для приложений, использующих angular в интерфейсе)
• Видеоразговор: обеспечение безопасности ваших приложений с помощью JWT (создателями jwt.io)
• Jwt.io (официальный сайт jwt)
• Jwt-Auth для Laravel (для тех, кто использует Laravel на заднем конце)

Каковы преимущества использования подхода на основе токенов?

Кросс-домен/CORS: cookie + CORS не хорошо работают в разных доменах. Подход на основе токенов позволяет вам совершать вызовы AJAX на любой сервер в любом домене, потому что вы используете HTTP-заголовок для передачи пользовательской информации. Stateless (масштабируемость на стороне сервера a.k.a.): нет необходимости хранить хранилище сеансов, токен является самоконфигурированным сущностью, которая передает всю информацию пользователя. Остальная часть штата живет в куки или локальном хранилище на стороне клиента.

CDN:вы можете обслуживать все активы вашего приложения из CDN (например, javascript, HTML, изображения и т.д.), а ваша серверная часть - это просто API. Развязка: вы не привязаны к конкретной схеме аутентификации. Маркер может быть сгенерирован в любом месте, поэтому ваш API можно вызывать из любого места с помощью одного способа аутентификации этих вызовов.

Подготовлено для мобильных устройств:, когда вы начинаете работать на родной платформе (iOS, Android, Windows 8 и т.д.), файлы cookie не идеальны при использовании защищенного API (вам приходится иметь дело с контейнерами cookie), Принятие подхода на основе токенов упрощает это. CSRF: поскольку вы не полагаетесь на файлы cookie, вам не нужно защищать от запросов на межсайтовый сайт (например, это не будет возможно для вашего сайта, генерировать запрос POST и повторно использовать существующий файл cookie для проверки подлинности, поскольку их не будет).

Производительность: мы не представляем здесь жесткие перфомансы, но в кругообороте сети (например, при поиске сеанса в базе данных), скорее всего, потребуется больше времени, чем вычисление HMACSHA256 для проверки токена и синтаксического анализа его содержание.

Страница входа не является особым случаем: Если вы используете Protractor для написания ваших функциональных тестов, вам не нужно обращаться с каким-либо специальным случаем для входа. Стандартно: ваш API может принять стандартный JSON Web Token (JWT). Это стандарт, и есть несколько базовых библиотек (.NET, Ruby, Java, Python, PHP) и компаний, поддерживающих их инфраструктуру (например, Firebase, Google, Microsoft). Например, Firebase позволяет своим клиентам использовать любой механизм проверки подлинности, пока вы создаете JWT с определенными заранее определенными свойствами и подписываетесь с общим секретом для вызова своего API.

Ответ 2

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

• Отправить email + password через ajax на сервер
• Сгенерируйте token на сервере и отправьте его обратно в приложение
• Сохранить email + token в localStorage
• Для каждого отдельного запроса, который я делаю на сервере, я отправляю email + token через POST
• На сервере я проверяю подлинность этого пользователя с этим токеном, если true выполняется метод, если false я отправляю обратно в приложение ошибку (401)
• Если приложение получает успех, тогда это нормально, если принимает ошибку, я перенаправляюсь на экран входа в систему.

Приятно, что когда приложение открыто, вы можете получить email + token с localStorage, отправить на сервер, если этот токен в порядке для этого пользователя, перенаправить на главный экран, иначе перенаправить чтобы залогиниться. Затем, когда пользователь очищает кеш приложения, он перенаправляется на экран входа в систему.

Ответ 3

Если вы ищете полный пример аутентификации, я могу порекомендовать Полное руководство для аутентификации пользователей с помощью AngularJS.

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

• поймать каждое событие изменения состояния
• улавливать каждый HTTP-запрос на сервер

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

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

Ответ 4

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

Я очень доволен результатом, в дополнение к проверке подлинности по электронной почте/паролю. Я добавил некоторую социальную аутентификацию, которая работает одинаково.

• открыть URL-адрес на стороне клиента с провайдером (facebook/твиттер/instagram) URL для входа
• пользователь входит в систему и перенаправляется на URL-адрес обратного вызова сервера (мой сервер написан в nodejs)
• Как только я получаю токен доступа у поставщика. Я сохраняю этот токен, а затем создаю токен для повторного использования клиентом каждый раз, когда пользователь хочет получить доступ к защищенному ресурсу.

Скачайте apk и протестируйте его.

Если это то, что вы ищете, вы можете проверить код на стороне клиента по адресу: https://github.com/malikov/Authenticate.me-client-cordova-ionic

И код на стороне сервера: https://github.com/malikov/Authenticate.me-Node-Server