Я нахожусь в середине разработки веб-приложения для социальных сетей PHP, которое будет поддерживаться различными веб-службами, каждый из которых работает с REST API. Веб-сервисы, вероятно, будут реализованы в Java с уровнем данных MySQL, но вся суть того, что я пытаюсь сделать, – это действительно упростить реализацию модулей на разных языках / хранилищах данных в зависимости от того, что является approriate.
Например, когда пользователь регистрируется в приложении через форму входа, код PHP подключается к веб-службе, а POST – имя пользователя и пароль, чтобы проверить, должны ли они быть аутентифицированы. Обычно я должен начать сеанс и хранить его в хранилище данных сеанса.
Другим примером может быть, если пользователь отправляет личное сообщение другому пользователю. Сообщение будет отправлено на веб-службу приватного обмена сообщениями, которая будет заботиться обо всем хранилище. Аналогичным образом с веб-службой можно связаться для извлечения сообщений для пользователя.
Хотя я понимаю, как реализовать веб-службу REST в Java и установить соединение с ней в PHP, я совершенно не уверен в том, как защитить передаваемые данные и убедиться, что это возвращаемые данные пользователей. Если, например, я хочу получить все пользовательские личные сообщения, как известно веб-службе, чтобы вернуть этих пользователей. Я мог бы передать этот идентификатор пользователей как часть URL-адреса GET, но, конечно же, любой старый пользователь мог бы просто вычислить URL-адрес GET и использовать его для поиска сообщений других людей. Я подумал, может быть, я могу передать идентификатор сеанса и IP-адрес, который позволит мне проверить хранилище данных сеанса и убедиться, что он правильный пользователь?
Чтобы защитить данные, которые важны – например, имя пользователя / пароль, я думал, что просто передам его через SSL.
Надеюсь, это объяснит мою проблему лучше.
благодаря
Взгляните на аутентификацию HTTP Digest. Большинство клиентов должны его поддерживать, и это означает, что данные аутентификации могут передаваться безопасно с каждым запросом как часть заголовков без вмешательства в полезную нагрузку самого запроса.
Я думаю, что требование OAuth – хороший выбор. Ваши конечные пользователи должны понимать, что другим веб-сайтам не нужно запрашивать имена пользователей и пароли для доступа к их данным. Что касается SSL, то это стоит делать, если можно. Вам нужно будет увидеть, является ли компромисс производительности приемлемым.
Имейте в виду, что ваш api должен имитировать HTTP-протокол.
Http является апатридом, и, добавив любые сеансы или около того, вы пытаетесь подделать метод «Alwaysconnected».
При использовании LoginForm мне нужно отправить два запроса для каждого вызова;)
Это в основном 2 вопроса.
Когда конфиденциальность является проблемой, я бы выбрал самый безопасный вариант: подавать данные через SSL (через HTTPS).
Что касается проверки подлинности, существует несколько возможностей. Базовый через SSL является одним из них, но простая форма входа с файлом cookie может быть другой. (Например, аутентификация ASP.Net Forms). Все зависит от того, как вы хотите реализовать свой механизм аутентификации.