Предотвратить Authlogic от создания сеанса / cookie для запросов не HTML - PullRequest
2 голосов
/ 13 декабря 2010

Я использую Authlogic и Rails 3. В дополнение к обычному пользовательскому интерфейсу на основе браузера (вход в систему с помощью форм и так далее) я хотел бы реализовать API.

Похоже, что Authlogic поддерживает одиночные токены доступа, которые по умолчанию не сохраняются. Я добавляю их, добавляя аргумент GET, как в:

/users.xml?user_credentails=my_single_access_token

Вопрос: Можно ли как-нибудь разрешить Authlogic принять ключ API через HTTP Basic Auth? Highrise делает что-то подобное, учитывая:

curl -u 605b32dd:X http://sample.highrisehq.com/people/1.xml

То же самое с Freshbooks :

curl -u insert_token_here:X https://sample.freshbooks.com/api/2.1/xml-in -d '[xml body here]'

Как бы я подражал этой функции? Я даже не могу понять, где взяты входные данные (постданные из форм, HTTP basic, API-токен). Я свел их к вызову UserSessions.find без аргументов, но я теряю его после есть.

Любая помощь будет принята с благодарностью!

Смежный вопрос: Я также хотел бы отключить сохранение сеанса (сделать так, чтобы cookie не сохранялся), если используется HTTP basic. Любая помощь в этом тоже будет признателен!

Ответы [ 3 ]

5 голосов
/ 05 января 2011

Если вы внедряете API, вы можете подумать о создании отдельного приложения Rack, которое затем монтируется в «/api/1.0 / ...» и разделяет ваши модели.

Таким образом, вы не привязываете себя к тому, что ваш API напрямую связан с вашими общедоступными маршрутами, что может быть сложно создать для пользователя API.

Хорошим подходом будет создание простогоПриложение Sinatra, которое предоставляет только те методы, которые вам нужны, а затем создает отдельную стратегию аутентификации:

require 'sinatra'    
require 'active_support' # all the Rails stuff
require 'lib/user' # your User class
require 'sinatra/respond_to' # gem install sinatra-respond_to

Sinatra::Application.register Sinatra::RespondTo

use Rack::Auth::Basic, "API", do |username, password|
  User.find_by_login(username).valid_password?(password)
end

get '/api/1.0/posts' do
  @posts = Post.recent # assuming you have a Post model...

  respond_to do |wants|
    wants.xml { @posts.to_xml }
    wants.to_json { @posts.to_json }
  end
end

get '/api/1.0/users/:id' do
  @user = User.find_by_login(params[:id])

  # Careful here - don't release personal details!
  respond_to do |wants|
    wants.xml { @user.to_xml }
    wants.to_json { @user.to_json }
  end
end

Управление версиями вашего API с «1.0» (или аналогичным) в пути означает, что если вы измените свойВ моделях вы можете создать новую версию своего API, не нарушая существующий код ваших пользователей.

Используя это, вы сможете разрешить пользователям проходить аутентификацию с помощью HTTP Basic в форме:

curl -u steven:password http://example.com/api/1.0/users/steven.xml
curl -u steven:password http://example.com/api/1.0/users/steven.json
curl -u steven:password http://example.com/api/1.0/posts.xml

Чтобы запустить это, сохраните его как 'api.rb', и либо запустите его как промежуточное программное обеспечение стойки, либо создайте файл 'config.ru' следующим образом:

require 'api'
run Sinatra::Application

А затем из этого каталога:

rackup
0 голосов
/ 06 января 2011

Простите, если я неправильно понял ваш вопрос, но я думаю, что ответ прост: «Нет».Вы смешиваете две метафоры здесь.Если вам нужен безопасный ключ API, используйте токен единого доступа;если вы хотите использовать базовую аутентификацию доступа http, вам нужен другой глиф base64 - и базовая аутентификация http не особенно безопасна (если не используется через https, что обычно нецелесообразно).

Подробнее:

Согласно википедии, http базовая аутентификация предназначена для предоставления имени пользователя и пароля в простом, стандартном, но довольно небезопасном глифе в кодировке base64.

Для использования базовогоя полагаю, что вы хотите сгенерировать глиф с помощью простого

Base64.encode64("#{user.name}:#{password}")

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

Но в результате получается, что этот зверь очень отличается от single_access_token, и эти два нельзя смешивать.

0 голосов
/ 13 декабря 2010

Отказ от ответственности: я не на 100% возможен в том смысле, в котором вы описываете, не нарушая основной функциональности Authlogic.

Первая проблема, с которой вы столкнетесь, заключается в том, что authlogic предотвращает использование токенов SSO для аутентификации, если только запрос ATOM или RSS не отменяет это, вам нужно передать параметр конфигурации, см. Здесь: http://rdoc.info/github/binarylogic/authlogic/master/Authlogic/Session/Params/Config

К основной проблеме: я не вижу никакого «простого» способа справиться с этой функциональностью, однако то, что вы могли бы сделать для чего-то вроде curl, это передать пользовательский токен как параметр (как параметр -G), так же, каквы бы при посещении URL.

cURL Документация: http://curl.haxx.se/docs/manpage.html

...