Лучшие практики для безопасных API?
Скажем, у меня есть веб-сайт, который имеет большую информацию о наших продуктах. Я хотел бы некоторых наших клиентов (включая нас!), чтобы смочь искать наши продукты для различных методов, включая:
1) Получение по запросу данных из Ajax призывает те прохладные данные возврата, JavaScripty-пути, 2) Создающие приложения для iPhone то использование те данные; 3) Наличие других веб-приложений использует те данные для их собственного конца.
Обычно, я просто создал бы API и был бы сделан с ним. Однако эти данные являются на самом деле мягко конфиденциальными - который должен сказать, что мы не хотим, чтобы наши конкуренты смогли искать все наши продукты каждое утро и затем автоматически установить их цены для подрезания нас. И мы также хотим смочь посмотреть на то, кто мог бы злоупотреблять системой, поэтому если чье-то совершение десяти миллионов сложных звонков к нашему API день и срывание наш сервер, мы можем отключить их.
Мой следующий логический шаг состоял бы в том, чтобы затем создать ключ разработчиков для ограничения доступа - который будет хорошо работать для веб-приложений, но не так для любых вызовов Ajax. (Поскольку я вижу его, они должны были бы обеспечить ключ в JavaScript, который находится в простом тексте и легко замечен, и следовательно нет на самом деле никакой безопасности вообще. Особенно, если мы использовали бы ключи наших собственных разработчиков на нашем сайте для совершения этих вызовов Ajax.)
Так мой вопрос: после оглядывания в OAuth и OpenID в течение некоторого времени, я не уверен, что существует решение, которое обработало бы все три из вышеупомянутого. Есть ли своего рода канонические "лучшие практики" для ключей разработчиков, или OAuth и OpenID могут обработать вызовы Ajax легко некоторым способом, который я имею уже к grok, или я пропускаю что-то полностью?
3 ответа
Я думаю, что двухсторонний протокол OAuth - это то, что вы хотите удовлетворить требованиям №2 и №3. Для №1 я бы предложил, чтобы вместо того, чтобы клиент делал JS-запросы непосредственно к вашему приложению, он мог бы вместо этого проксировать эти запросы через свое собственное веб-приложение.
Промежуточное решение - потребовать ключ API; а затем потребовать, чтобы тот, кто его использует, на самом деле не использовал его напрямую с AJAX; но оберните их вызовы в запрос на стороне сервера, например:
AJAX -> customer server -> your server -> customer server -> user
Создание простого PHP API для заинтересованных сторон не должно быть слишком сложным, и ваши собственные приложения для iPhone, очевидно, вырежут среднего человека, поставляя их с собственным ключом API .
Маловероятно, что OAuth и OpenID имеют прямое отношение к вызовам AJAX. Скорее всего, у вас будет какой-то фильтр авторизации перед обработчиком AJAX, который проверяет файл cookie, и, возможно, этот файл cookie устанавливается в результате аутентификации OpenID.
Похоже, это сводится к вопросу « как мне предотвратить выскабливание экрана ». Если только зарегистрированные клиенты могут видеть цены, это одно, но если предположить, что вы похожи на большинство розничных сайтов, и ваш барьер для регистрации клиентов настолько низкий, насколько это возможно, это на самом деле не помогает.
И, эй, если ваши цены недоступны , вы не сможете отображаться в поисковых системах, таких как Froogle, Nextag или PriceGrabber. Но это скорее решение бизнес-стратегии, а не программирования.