2013-09-19 2 views
17

Я выбрал MySQL после поиска между MySQL и SQLite для доступа, потому что моему iPhone-приложению нужно извлекать информацию из онлайн-базы данных, которая уже находится в MySQL.Доступ к базе данных безопасно из приложения iOS

Я считаю, что традиционным способом доступа к информации было бы: иметь php-файл на сервере, который выполняет доступ для вас.

Приложение iPhone будет называть этот php-файл, и оно вернет результаты.

Приложение iOS вызывается http://somewebsite.com/index.php?id=234, и на веб-сайте будет напечатано имя пользователя id = 234.

What happens in the background of an iPhone app

Теперь, как надежен этот процесс? ... Я бы, очевидно, использовал подготовленные заявления и https. Но что, если кто-то нашел URL для этого сайта? Как защитить себя от неправильного использования (кто-то может создать список всех моих пользователей)? Является ли это стандартным способом подключения вашего iPhone-приложения и получения информации из базы данных?


Edit: Кроме того, позволяет сказать, что мне нужно, чтобы создать страницу приложение для входа ... У меня есть база данных MySQL с именем пользователя и паролем (хеширован очевидно). Было бы безопасно использовать переменные $ _GET для проверки подлинности. Например, например: https://somewebsite.com/checkauth.php?username=test&password=C3LyiJvTCQ14Q и распечатать php да или нет. Примеры изображения ниже:

This is how the iPhone would authenticate a user This is how the iPhone would authenticate a user

Я предполагаю, что выше метод не будет безопасно ... но мне нужно быть просветленным.

Кроме того, я предпочел бы избегать вызова базы данных в приложении с использованием стороннего API, не поддерживаемого Apple.

+0

Как вы считаете, вне зависимости от вашего интереса вы использовали сторонний поставщик OAuth для вашей аутентификации? Например: http://stackoverflow.com/questions/10296833/oauth-authentication-iphone – Tom

+0

Почему бы вам не использовать только одну из многих замечательных [рамок для веб-приложений] (http://en.wikipedia.org/wiki/ Comparison_of_web_application_frameworks)? Кроме того, существуют учебные пособия для начинающих, практически для любого веб-приложения, которое проклятия также охватывает безопасность и, возможно, также имеет пример входа. – CouchDeveloper

ответ

20

Лучший способ пойти об этом будет настроить учетную API для взаимодействия с базой данных на сервере и приложение iPhone просто запрашивает API и возвращает данные в машиночитаемом формате, например, JSON см http://en.wikipedia.org/wiki/JSON и http://json.org/.Таким образом, для пользователя Логин сервер будет возвращать, может быть что-то вроде:

{ 
    "result": false, 
    "error": "Invalid username or password" 
} 

Это будет сгенерировано с помощью PHP с помощью следующего кода:

echo json_encode(array(
    "result" => false, 
    "error" => "Invalid username or password" 
)); 

Также обратите внимание, что вы должны использовать HTTP response codes в сочетании с этим, например, 401 для несанкционированного доступа.

JSON может использовать в своем формате логические и другие структуры данных. У почти всех основных языков есть поддержка/библиотеки.

Преимущества этого в том, что он позволяет создавать другие приложения, используя тот же API, такой как версия Android или фактический веб-сайт.

Это SO вопрос является хорошей отправной точкой на безопасности мобильных приложений:

Creating an API for mobile applications - Authentication and Authorization

Основные моменты обязательно используйте HTTPS. При отправке учетных данных пользователя вы можете вернуть токен пользователя (ключ api), который может быть использован для будущих запросов и сохранен в приложении iPhone для будущего доступа.

Например: https://iphoneapp.com/notifications.json?key=98fy92473r92hAAIYEFG397qbqwiuUEAF

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

Примечание: Это просто случайная строка печатается на клавиатура.

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

Еще одним огромным преимуществом является создание API, который использует ваше собственное приложение, что он будет поддерживаться высоким стандартом, а другие сторонние компании также могут использовать API (если вы разрешите им).

Edit: Кроме того, позволяет сказать, что мне нужно, чтобы создать страницу приложение для входа ... Я есть база данных MySQL с именем пользователя и паролем (хеширован очевидно). Было бы безопасно использовать переменные $ _GET для проверки подлинности . Как, например: https://somewebsite.com/checkauth.php?username=test&password=C3LyiJvTCQ14Q

Вы должны послать, что конфиденциальные данные с помощью POST вместо этого, но любая услуга должна войти в какой-то момент. Использование HTTPS должно помочь, поскольку оно предотвращает подслушивание. После первой проверки подлинности вы можете вернуть токен и воспользоваться преимуществами, упомянутыми выше.

Что касается логина пользователя, как и ваш PHP, соответствующий хорошей практике, у вас не должно быть проблем. См. http://www.phptherightway.com/, это очень поможет, если у вас есть вопросы.

Определенно исследуйте OAuth и используйте это, если хотите.

Это всего лишь отправная точка и НЕ предназначается для слова «слово в слово», требуется дополнительное чтение и поиск в Интернете.

+0

* «Вы должны отправить эти конфиденциальные данные, используя POST, но любая служба должна войти в какой-либо момент. Использование HTTPS должно помочь, поскольку оно предотвращает подслушивание». * Только второе предложение имеет какое-либо значение здесь. 'POST' не более безопасен, чем' GET'. –

+0

@ lwburk Я не упоминал, что использование одного метода HTTP имело какую-либо пользу. Что делать, если возникает некоторая ошибка и отображается URL-адрес? Параметры 'GET' могут быть легче видны пользователю, когда нет необходимости. Я понимаю вашу точку зрения. – SamV

+0

Использование 'POST' для обеспечения безопасности - это как писать секрет на открытке, а затем утверждать, что секрет более безопасен, если карта кладет на стол тайной стороной вниз. Это не имеет значения. Любой может перевернуть карту. –

-9

Если вы хотите получить доступ к базе данных из приложения IOS и сохранить данные в базе данных, вам необходимо использовать middleware solutio.

который WebService

Создание веб-сервера В Microsoft ASP Dot Net и доступа, которые WebService в IOS Применение При том, что вы можете общаться между двумя разными операционными системами.

возвращение из Webservice является XMLdoucment, который может быть дополнительно обработать с XML казначея.

+0

Я так понимаю, но насколько безопасно использовать промежуточное решение ... например, я бы использовал PHP в качестве своего промежуточного программного обеспечения. –

2

Если вы ищете альтернативу «строить API с нуля», мы использовали веб-сервис Kumulos, доступный на kumulos.com, для быстрого и простого решения.

Эта служба позволяет разработчику подключаться к базе данных MySQL и создавать модель данных и API через веб-страницу, а затем развертывать на вашей платформе собственную библиотеку. Я считаю, что вы также можете импортировать существующую модель данных.

После того как модель данных построена на веб-странице, вы можете создавать API-интерфейсы и указывать входные и выходные параметры. API-интерфейсы моделируются на основе типа выполняемой вами операции SQL, такой как SELECT, UPDATE, INSERT, DELETE.

В вашем случае вы хотите смоделировать интерфейс входа/авторизации, который принимает имя пользователя и (хешированный) пароль, проверяет данные в таблице Users и возвращает результаты проверки подлинности.

После того как ваши API-интерфейсы смоделированы с помощью веб-страницы, вы сможете «развернуть» вашу конфигурацию и сгенерировать родные библиотеки для iOS, Android, PHP и других.

Сгенерированная библиотека Obj C распадается в ваш проект, и вы делаете и отвечаете на API, используя объективные вызовы c и делегаты.

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

У нас было несколько вопросов или вопросов поддержки за последние несколько месяцев, и их поддержка была на высшем уровне. Их основой является Rackspace. На данный момент у нас есть около 8 или 10 производственных приложений, на которых запущены API, и они вполне довольны тем, что не нанимают разработчика API.

2

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

Первым уровнем защиты вашего API может быть создание «ключа API», который идентифицирует приложение. Этот ключ хранится на сервере и проверяется при каждом запросе. Запрос без ключа API должен возвращать код статуса HTTP 401 (неавторизованный).

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

Я не рекомендую использовать имя пользователя/пароль для каждого запроса, вместо этого пользователь должен пройти аутентификацию один раз и позволить серверу отправлять маркеры аутентификации, которые могут быть использованы приложением для выполнения будущих аутентифицированных вызовов. Взгляните на OAuth2 как на потенциальную схему авторизации. Также просмотрите OAuth 2.0 - The Good, the Bad & the Ugly.

Предлагаю использовать BShaffer OAuth2 Server in PHP. Также см. Best Practices for securing a REST API/web service для альтернатив.

С вашего вопроса кажется, что существует существующая подсистема, я рекомендую создать простой интерфейс, который упрощает использование подсистемы и многократно используется для нескольких клиентов вместо того, чтобы модифицировать подсистему для размещения API.Это обычно называют Facade Design Pattern.

Многие PHP-платформы имеют пакеты для реализации пользовательских API-интерфейсов RESTlike. Symfony имеет FOSRestBundle, FuelPHP имеет контроллер REST из коробки, а CodeIgniter - REST server.

Резюмируя:

  1. Создание простого интерфейса для доступа к информации из существующей системы (REST API).
  2. Защитите свою личную информацию с помощью надлежащего механизма аутентификации (возможно, OAuth2).
  3. Используйте существующие библиотеки и/или фреймворки для ускорения разработки.
  4. В результате ваш код будет повторно использоваться для нескольких приложений и платформ!
Смежные вопросы