Используя authlogic_api для направляющих REST доступ API

Я пишу бэкенду направляющих API для Паровой игры, к которой только получают доступ через вызовы REST, таким образом, никакая определенная для пользователя аутентификация не требуется. Я пытаюсь реализовать authlogic_api плагин для драгоценного камня Authlogic, который использует api_key/signature механизм для ограничения доступа. Я реализовал модели ApplicationSession и ApplicationAccount, как обрисовано в общих чертах в rdocs, но я не уверен, как изменить мой ApplicationController для ограничения доступа.

Смотря на источник, кажется, что authlogic_api плагин изменяет модули ActsAsAuthentic и Сессии от Authlogic. Но так как это - аутентификация чрезвычайно "одиночного обращения", требуя, чтобы ключ API и подпись были переданы каждому запросу, я не вижу, как сессии были бы фактором.

Кто-либо успешно реализовал authlogic_api в их приложениях? Если так, Вы совместно использовали бы свой подход для установки Вашего ApplicationController?

7
задан shingara 25 June 2010 в 07:51
поделиться

2 ответа

Возможно, вам не нужны накладные расходы Authlogic.

Если вы генерируете URL, который затем будет отправлен клиенту, просто добавьте временную метку истечения срока действия и сделайте MD5-хэш (подпись) для всего URL, добавив результат в качестве последнего параметра запроса.

Пожалуйста, установите фильтр before_filter на действие контроллера, т.е. метод signed_url, который будет проверять URL. Этот метод должен получить URL из объекта запроса. Убедитесь, что срок действия не истек. Удалите подпись из URL, чтобы поместить ее в ту же форму, которая использовалась для генерации оригинального URL, сделайте это и проверьте совпадение. Вуаля.

Истечение срока действия важно для того, чтобы убедиться, что URL-адреса не могут быть повторно использованы в дальнейшем.

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

0
ответ дан 7 December 2019 в 14:28
поделиться

Решили эту проблему, следуя примеру Authlogic , и просто заменив модель ClientAccount на модель пользователя. Итак, в моем контроллере приложения у меня есть:

before_filter :require_client

def require_client
  unless current_client
    store_location
    render :text => 'Authentication failed', :status => 401
    return false
  end
end

def require_no_client
  if current_client
    store_location
    render :text => 'Client session already exists', :status => 401
    return false
  end
end

def current_client_session
  return @current_client_session if defined?(@current_client_session)
  @current_client_session = ClientSession.find
end

def current_client
  return @current_client if defined?(@current_client)
  @current_client = current_client_session && current_client_session.record
end

Модель ClientAccount act_as_authentic, а модель ClientSession обрабатывает создание и уничтожение сеансов для Authlogic (authenticate_with ClientAccount):

class ClientSessionsController < ApplicationController
  before_filter :require_no_client, :only => [:new, :create]
  before_filter :require_client, :only => :destroy

  def new
    @client_session = ClientSession.new
  end

  def create
    @client_session = ClientSession.new(params[:client_session])
    if @client_session.save
      redirect_back_or_default account_url
    else
      render :action => :new
    end
  end

  def destroy
    current_client_session.destroy
    redirect_back_or_default new_client_session_url
  end
end

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

0
ответ дан 7 December 2019 в 14:28
поделиться
Другие вопросы по тегам:

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