Ответ 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.