Платформы MVC, уровни API и аутентификация / разрешения - PullRequest
1 голос
/ 24 февраля 2011

Я задавал вопрос ранее, однако он мог быть слишком расплывчатым или широким, чтобы оправдать ответ.С тех пор я пересмотрел свой подход и свой вопрос.

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

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

Уровень веб-доступапо сути, то же самое, что и уровень API, единственное отличие заключается в методе вывода (HTML против JSON), поэтому я подумал, что общий уровень бизнес-логики для них будет иметь смысл.Запросы будут нормализованы к структуре данных и отправлены в бизнес-логику.В конечном итоге бизнес-логика выявляет структуру данных результатов (результаты запросов, неудачи, успехи и т. Д.), Которые либо передаются в механизм шаблонов, либо сериализуются в JSON.

Мне кажется, что для проверки разрешений требуетсябыть выполненным на уровне общей бизнес-логики, но есть ли лучшее место для включения этого в инфраструктуру MVC / API?

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

Ответы [ 2 ]

2 голосов
/ 24 февраля 2011

Как вы планируете разрешить пользователям доступ к API?

Вот как я делаю авторизацию на основе ролей:

  • Каждый контроллер обычно имеет несколько действий (методов), которые доступны для внешнего интерфейса, например,
    • function action_get($id)
    • function action_delete($id)
  • Каждый контроллер имеет свойство класса, которое определяет, какие роли требуются для каждого действия, например,
    protected $access = array(
        'get' => NULL,  // everybody can access; this line isnt necessary though
        'delete' => array('admin')  // only admins can access
    )
  • Метод before() запускается перед выполнением действия. Он выполняет проверку авторизации на основе списка доступа $.
  • Каждое действие отвечает за определение того, что выводить, например,
public function action_get($id) {
      // Business logic... build data structure
      # ...

      if (Request::is_ajax()) {
          // Output JSON
      }
      else {
          // Output HTML
      }
  }

Эта система может быть легко расширена для поддержки вызовов API. Либо разверните выходную часть метода, определяя, является ли он запросом API, либо просто создайте другое действие специально для вызова API. Если вы выбираете последний метод и хотите сохранить свой код СУХИМ, переместите бизнес-логику для структуры данных в вспомогательный метод (например, protected function _get()). Могут быть и более эффективные способы предоставления доступа и обработки API. Это действительно зависит от того, как вы хотите разрешить доступ и насколько гибко / сухо вы хотите его сделать.

1 голос
/ 24 февраля 2011

В общем, аутентификация выполняется на уровне контроллера (обычно в конструкторе класса контроллера, поэтому он вызывается для каждого метода в этом контроллере). Конечно, у вас есть некоторые данные о пользователях / ролях в моделях, но контроллер сравнивает запрос с разрешениями и т. Д. И разрешает метод или нет (и тогда метод решит вывести html, json, или что угодно).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...