2013-05-16 4 views
3

Ситуация: рельсы 3.2 приложение с демо-периодом, после которого пользователи должны начать оплачивать услугу.Каковы наилучшие методы авторизации?

Вопрос: Если пользователь не добавляет способ оплаты или не выбирает план платежей, каков рекомендуемый способ ограничения доступа пользователей к «платной» части веб-приложения?

мне нужно что-то, что сортирует пользователей следующим образом:

if user.admin? || user.in_demo || user.has_all_payment_data 
    # carry on 
elsif user.should_add_payment_method 
    # send them to add payment method page 
elsif user.should_choose_plan 
    # send them to add plan 
else 
    # redirect to home page or whatever 
end 

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

+0

DEPA, спасибо за ваши изменения. Просто добавлю, что у нас уже есть авторизация с точки зрения пользователя/пароля и администратора - я просто не знаю, как лучше всего это расширить, чтобы включить статус оплаты пользователя. – omnikron

+1

Я полагаю, вы хотите сказать, что у вас уже есть аутентификация, что-то другое. – depa

+0

вы совершенно правы! Я не обманывал разницу между этими двумя понятиями. Так много всего это просто знать, какой термин для google ... – omnikron

ответ

2

Существует сообщение Джонаса Никласа (создателя Capybara и CarrierWave), в котором он подробно объясняет, как использовать более простой подход, чем CanCan's. Его подход основан на дополнительном простом классе Ruby для каждой модели, для которой вы хотите создать правила авторизации.

Simple authorization in Ruby on Rails apps (Elabs blog)

Они разгружены, что решение в драгоценный камень по имени Пандит, но это действительно кажется достаточно простым, чтобы быть в состоянии осуществить с нуля.

Pundit gem (GitHub)

+0

ах, это больше похоже на то, что я не видел эту статью. Я очень предпочитаю этот подход к cancan's, и я полностью согласен с тем, что репозиторий cancan выиграет от предоставления еще нескольких прав человека. Я думаю, что мы пойдем на реализацию чего-то подобного. Большое спасибо! – omnikron

1

Я хотел бы предложить before_filter в контроллере приложения, а затем с помощью skip_filter в отдельных контроллерах, чтобы обойти его за действия, которые неоплачиваемые пользователи могут получить доступ, например:

class ApplicationController < ActionController::Base 
    before_filter :check_payment 
    ... 
end 

class UserController < ApplicationController 
    skip_filter :check_payment, :only => [:login, :logout, ...] 
    ... 
end 

Это сохраняет доступ, содержащийся в соответствующем контроллеров, а не нуждающихся в более крупном :except => ... на самом фильтре.

+0

спасибо - это именно то, что у нас уже есть, извините, если я не объяснил это достаточно хорошо в вопросе. Я ищу альтернативу этому, поскольку он не очень хорошо масштабируется со сложностью. – omnikron

+0

Является ли это сложностью самого фильтра, или просто количество действий, которые вы должны включить/исключить? – DaveMongoose

+0

Сложность в самом фильтре - у нас довольно много разных состояний, и это просто слишком запутанно.Я думаю, что cancan - это путь вперед, я слишком быстро его отпустил. – omnikron

Смежные вопросы