Использование многоуровневой структуры Drupal 7 для стратегии ReSTful API и стратегии Auth

Мое положение

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

Мой план

Почему Drupal? Ну, я знаю Drupal, и я могу представить себе установку, в которой у меня есть 2 сайта. www.mygui.com (по умолчанию) и api.mygui.com (API). Вся структура базы данных определяется работой, выполняемой на сайте по умолчанию . Используя Drupal Services Module (и только несколько других необходимых модулей ядра) на сайте API , я планирую разрешить аутентифицированные обновления базы данных с помощью JSON и drupal_internal_api.

Моя проблема

У меня уже есть прототип (не в drupal), который использует токены. Я новичок в сервисах и пока не знаю всех его ограничений и возможностей. Это выглядит многообещающе, но все еще в стадии разработки: Модуль аутентификации для Drupal Services . Я бы хотел получить советы или ресурсы относительно хорошей стратегии аутентификации. Например, что лучше? Сохранять ли пользовательскую базу с назначенными ролями «API Uer» или иметь полностью отдельную пользовательскую базу специально для сайта API ? Помните, что имя пользователя API - это долгосрочная настройка, когда имя пользователя /пароль или токен не должны меняться, пока пользователь API не будет готов с новой версией приложения? Могу ли я иметь удобный графический интерфейс для пользователей для управления учетными данными сайта API на сайте по умолчанию ?

5 голосов | спросил Akahadaka 20 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowThu, 20 Sep 2012 14:40:19 +0400 2012, 14:40:19

1 ответ


0

Это, безусловно, может быть достигнуто без какого-либо многообразия. Это означает, что вы всегда можете разместить API на одном и том же сайте и проксировать путь api.mysite.com до mysite.com/api, что позволит ему быть невидимым для пользователя. (Убедитесь, что ваш веб-хост поддерживает mod_proxy или у вас есть внешний прокси-сервер, который вы можете использовать для этой задачи)

Что касается фактической аутентификации, я не беспокоюсь о токенах. Используйте учетные данные. Таким образом, люди могут получить и сохранить сеанс (в соответствии с тем, сколько вы хотите, чтобы они были основаны на session_lifetime в ваших настройках.php). После первоначального вызова пути входа в систему они могут впоследствии вызвать API снова и снова путем передачи уникальной сессии, которую они назначили.

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

ответил webkenny 1 FebruaryEurope/MoscowbFri, 01 Feb 2013 09:34:28 +0400000000amFri, 01 Feb 2013 09:34:28 +040013 2013, 09:34:28

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132