Strona Andrzeja Kardasia

Jak wykorzystać ACL9 do obsługi autoryzacji w połączeniu z Authlogic do obsługi uwierzytelnienia

W większości serwisów Internetowych deweloperzy nie muszą tworzyć kompleksowych rozwiązań autoryzacyjnych, wszystko czego im potrzeba to zarządzanie dostępem na podstawie prostego weryfikowania loginu i hasła. Jeśli użytkownik się zalogował ma dostęp do wszystkich funkcji serwisu, jeśli się nie zalogował, jedyne co może zrobić to zalogować się. W Ruby On Rails można to osiąnąc względnie prosto używając Authlogica. Jeśli prześledzisz screencast Ryan Bates'a dotyczący Authlogica nauczysz się jak to zrobić.

W projekcie nad którym pracowałem, potrzebowałem znacznie bardziej zaawansowanego rozwiązania. To czego potrzebowałem to:

• możliwości kontrolowania dostępu opartego o różne role użytkowników
• możliwości kontrolowania dostępu na poziomie akcji kontrolera
• możliwości zmiany ról użytkowników w czasie wykonywania aplikacji
• możliwości kontrolowania dostępu na poziomie modelu

Zdążyłem się już przyzwyczaić do tego, że w Ruby On Rails ktoś już napisał API, którego mogę użyć. Wszystko co musiałem zrobić to zainstalować wtyczkę autoryzacyjną ACL9:

script/plugin install git://github.com/be9/acl9.git

Postaram się tutaj pokazać jak pomocne jest API ACL9, poprzez zaprezentowanie małych fragmentów kodu z mojego projektu.

Pierwszą rzecz jaką musisz zrobić jest pozwolenia aby twój system przechwycił specjalny wyjątek, który zostanie wyrzucony kiedy wystąpi problem z autoryzacją. Możesz to zrobić dodając jedną linię kodu do twojego głównego kontrolera aplikacji.

rescue_from 'Acl9::AccessDenied', :with => :access_denied

Następnie musisz zdefiniować akcję access_denided w twoim kontrolerze aplikacji. Moja wygląda następująco:

def access_denied
    if current_user
      flash[:error] = "Security problem!"
      respond_to do |format|
        format.html {redirect_to :controller => "szws", :action =>"denied"}
        format.js {
          render :update do |page|
            page.redirect_to :controller => "szws", :action =>"denied"
        end
        }
      end 
    else
      flash[:notice] = "You have to be loged in to see this page"
      respond_to do |format|
        format.html {redirect_to login_path}
        format.js {
          render :update do |page|
            page.redirect_to login_path
          end
        }
      end
    end
  end

Jak widzisz ta akcja obsługuje dwa przypadki. Pierwszy kiedy użytkownik jest zalogowany i zgłoszony zostanie wyjątek, wyświetlimy użytkownikowi wiadomość flash z odpowiednim komunikatem i przekierujemy go do specjalnej akcji w jednym kontrolerów. Ta akcja wygeneruje stronę ze szczegółowym opisem błędu. Drugi jeśli użytkownik nie jest zalogowany (niedostępny jest obiekt current_user) wyświetlamy odpowiednią informację i przekierowujemy użytkownika do strony logowania.

Jak pewnie zauważyłeś mój system dzięki wykorzystaniu bloku kodu respond_to będzie poprawnie reagował na błędy autoryzacji generowane zarówno podczas normalnego żądania html jak i żądania typu xmlHTTPRequest generowanego przez wywołania Ajaxowe.

Co jest genialną rzeczą w ACL9 to bezpośrednia integracja z rozwiązaniem uwierzytelniającym, którego używam. Obie usługi wykorzystują obiekt current_user do zarządzania statusem logowania użytkownika. Możesz być zainteresowany otrzymaniem odpowiedzi na pytanie: Co należy zrobić kiedy chcesz sprawdzić dostęp użytkownika na podstawie jego statusu logowania? Spójrz na część kodu kontrolera user_session:

access_control :debug => true do
  allow logged_in, :to => [:destroy]
  allow anonymous, :to => [:new, :create]
end

Tutaj możesz zauważyć podstawową kontrole dostępu na podstawie statusu logowania. Ta mała część kodu jak jest napisane w API ACL9 stworzy poprzedzający filtr, który dokona sprawdzenia dostępu przez wykonaniem akcji naszego kontrolera. To co tu widzimy to to, że zalogowany użytkownik może wykonać akcję destroy, która obsługuje operację wylogowania, a dowolny niezalogowany użytkownik (anonymous) może wykonać akcje new i create, tak więc ma dostęp do strony logowania (akcja new) i może podjąć próbę zalogowania się (akcja create). Istnieje także jeszcze jedna przedefiniowana rola nazwana all. Jeśli użyjesz allow all to oznacza to, że operacje zawsze będą dostępne. Możesz także użyć deny zamiast allow aby upewnić się, że ktoś nie ma możliwości zrobienia czegoś. Zalecam wszystkim zatrzymanie :debug => true w fazie rozwijania projektu, ułatwi to znalezienie problemu jeśli coś nieoczekiwanego zacznie się dziać z częścią kodu odpowiedzialnego za autoryzację.

Spójrzmy teraz na autoryzację opartą o role. Rozpoczniemy od zajrzenia do kodu źródłowego mojego modulu użytkownika

class User < ActiveRecord::Base
  #This is authentication subject
  acts_as_authentic do |c|
     c.validate_email_field = false
     c.validate_login_field = true
     #make sure that one workshop wont be able to have two users of the same name
     c.validations_scope = :workshop_id
     c.logged_in_timeout=30.minutes;
     c.maintain_sessions=false
     c.ignore_blank_passwords=false
  end
  #This is authorization subject
  acts_as_authorization_subject
  #This is also an authorization object
  acts_as_authorization_object
 
  belongs_to :workshop
 
  after_create :make_owner, :assign_security_roles
 
  def self.find_user_in_workshop(login)
    workshop_unique=login[:workshop_unique]
    username = login[:username]
    workshop = Workshop.find_by_workshop_unique(workshop_unique)
    unless workshop.nil?
      find_by_username_and_workshop_id(username,workshop.id)
    else
      return nil
    end
  end
 
   #Assign new user to standard security grups
  def assign_security_roles
    unless self.undeletable
      self.has_role! :warehouseman
      self.has_role! :dispatcher
    end
  end
 
  #Make user owner of his data
  def make_owner
    self.has_role!(:owner,self)
  end
 
end

Pominiemy część kodu dotyczącą Authlogica i skupimy się na liniach używających API ACL9. Pierwszą rzeczą jaką widzimy jest acts_as_authorization_subject, to pozwala nam przypisywać role do dowolnego użytkownika. Druga rzecz to coś co uwielbiam w ACL9: acts_as_authorization_object, to pozwala nam przypisywać prawa dostępu na poziomie modelu. Dzięki temu możemy przypisać uprawnienia do dowolnej instancji danego obiektu. Jeśli spojrzysz głębiej w kod modelu użytkownika znajdziesz tam konkretne przykłady użycia. Metoda assign_security_roles pokazuje jak dopisać rolę do podmiotu autoryzacji. Możesz to zrobić poprzez proste wywołanie object.has_role! :role_name. Czynimy tutaj naszego użytkownika członkiem ról dispatcher i warehouseman. Metoda make_owner pokazuje jak zdefiniować autoryzację na poziomie modelu. Jest to również proste wywołanie: object.has_role!(:role_name,authorization_object). W ten sposób upewniam się, że każdy użytkownik będzie właścicielem swoich danych. To pozwoli mojemu użytkownikowi edytować jego własny profil bez względu na przynależność do ról systemowych. Jak widzisz obie metody są wywołane w call backu after_create w ten sposób każdy tworzony użytkownik będzie właścicielem swoich danych i będzie przypisany do domyślnych ról bezpieczeństwa.

Teraz możemy spojrzeć jak używać kontroli autoryzacji opartej o role w kontrolerach. Spójrz na kod ACL9 z mojego kontrolera users.

access_control :debug => true do
    allow :admin, :manager
    allow :owner, :of => :user, :to => [:edituser,:update,:destroy,:changepasswd,:dochangepasswd]
end

Najpierw pozwalamy na wykonanie wszystkich akcji dostępnych w naszym kontrolerze users rolom admin i manager. Następnie pozwalamy właścicielowi (owner) instancji obiektu user wykonywać tylko wymienione akcje. Ta część kodu pozwala naszym użytkownikom w pełnym zakresie zarządzać ich profilami. Jeśli potrzebujesz możesz także użyć wywołania except zamiast to definiując listę akcji.

Jeśli zabraniamy wykonywać pewnych zadań naszym użytkownikom, zdecydowanie lepiej jest nie wyświetlać im tych zadań. W ACL9 możesz osiągnąć to w prosty sposób. Spójrz na przykład menu poniżej:

<div id="menu">
<ul>
<li><%= link_to "Warsztat", root_path %></li>
<% if (current_user.has_role? :admin) %>
<%= render :partial => "admin_menu" %>
<% elsif (current_user.has_role? :dispatcher) %>
<li><%= link_to "Notification", :controller => "notifications", 
     :action => "index" %></li>
<li><%= link_to "Customers", :controller => "customers", 
     :action => "index" %></li>
<% elsif (current_user.has_role? :manager) %>
<li><%= link_to "Employees", :controller => "workers", 
     :action => "index" %></li>
<li><%= link_to "Administration", :controller => "settings", 
     :action => "index" %></li>
<% elsif (current_user.has_role? :warehouseman) %>
<li><%= link_to "Warehouse", :controller => "parts", 
     :action => "index" %></li>
<% end %>
</ul>
</div>

Jak widzisz sprawdzanie ról może być wykonane poprzez proste wywołanie object.has_role? role_name. Authlogic zajmuje się tworzeniem i zarządzaniem obiektem current_user, tak więc dzięki ACL9 i Authlogicowi mogę wyświetlić użytkownikom menu zależnie od ich uprawnień w systemie.

Właśnie w ten sposób używam ACL9 w mojej aplikacji. Jest możliwe, że znajdziesz bardziej interesujące rzeczy w API, więc upewnij się, że je przeczytasz, zanim użyjesz tej świetnej wtyczki Railsów.

Sources

• Strona kodu ACL9 na GitHub
• Czysta dokumentacja API ACL9