[RUBY] API-basierte Steuerung mit cancancan

Überblick

Ich denke, beim Erstellen eines Web-Systems gibt es relativ viele Anforderungen, um "Berechtigungen für jeden Benutzer zu verwalten".

Mit Ruby on Rails können Sie Berechtigungen mithilfe eines Gems namens cancancan verwalten, mit dem Ausführungsberechtigungen (Lesen / Schreiben) für das Modell verwaltet werden. Die grundlegende Verwendung ist zu tun.

Dieses Mal besteht die Anforderung, dass "Ich möchte die Ausführungsberechtigung der API verwalten", und ich habe untersucht, wie dies zu tun ist, und habe es daher zusammengefasst.

allgemeine Verwendung von Cancancan (modellbasierte Steuerung)

Bevor ich zum Hauptthema komme, werde ich kurz die allgemeine Verwendung von Cancancan (modellbasierte Steuerung) vorstellen. (Fast eine japanische Übersetzung von Gem's Readme)

Installieren Sie Gem

Fügen Sie Ihrem Gemfile Folgendes hinzu.

gem 'cancancan'

Definition der Fähigkeit

Die einem Benutzer erteilten Berechtigungen werden in der Klasse "Fähigkeit" definiert. Erstellen Sie zunächst die Klasse "Ability" mit dem folgenden Befehl.

rails g cancan:ability

Steuern Sie beispielsweise die Ausführungsberechtigung des Modells Post.

class Ability
  include CanCan::Ability

  def initialize(user)
    can :read, Post, public: true  # public=Jeder kann die wahre Aufzeichnung sehen

    if user.present?  #Definieren Sie zusätzliche Anmeldebenutzerberechtigungen
      can :read, Post, user_id: user.id  # user_Sie können auch auf Datensätze verweisen, deren ID Ihre eigene ist

      if user.admin?  #Definieren Sie zusätzliche Berechtigungen für den Administrator
        can :read, Post  #Alle Datensätze können referenziert werden
      end
    end
  end
end

cancancan hat ein reichhaltiges Wiki und dort sind auch detaillierte Definitionsmethoden organisiert. Defining Abilities - cancancan

Bestätigung der Autorität

Beim Überprüfen von Berechtigungen in einer Ansicht

<% if can? :read, @post %>
  <%= link_to "View", @post %>
<% end %>

Sie können überprüfen, ob der Benutzer die Leseberechtigung für die Variable "@ post" mit "can?: Read, @ post" hat. Im obigen Beispiel wird der Link nur angezeigt, wenn Sie die Referenzberechtigung von "@ post" haben. Weitere Informationen zu den in der Ansicht verfügbaren Helfern finden Sie auf den folgenden Seiten im Wiki. Checking Abilities - cancancan

Bei der Überprüfung der Berechtigungen auf dem Controller

Voraussetzung ist, dass die Methode current_user auf den angemeldeten Benutzer verweisen kann. Installieren Sie Authentifizierungsedelsteine wie Devise und Authlogic vor.

def show
  @post = Post.find(params[:id])
  authorize! :read, @post  # current_Nutzer@Fehler, wenn der Beitrag nicht referenziert werden kann
end

Wenn Sie "load_and_authorize_resource" schreiben, wird "before_action" hinzugefügt, um die Ressource zu lesen und die Berechtigung anhand des Controllernamens zu überprüfen. Sie können load_and_authorize_resource verwenden, um die Situation zu verhindern, in der Sie vergessen haben , authorize zu schreiben! In der Aktion, die Sie später hinzugefügt und die Berechtigungsprüfung verpasst haben. "

class PostsController < ApplicationController
  load_and_authorize_resource

  def show  # GET /posts/:post_Wird beim Zugriff auf die ID aufgerufen
    # before_Führen Sie die folgenden Schritte in Aktion aus
    # @post = Post.find(params[:post_id])
    # authorize! :show, @post
  end
end

Zusatzinformationen

Die folgenden Aliase werden intern in Cancancan geschnitten.

alias_action :index, :show, :to => :read
alias_action :new, :to => :create
alias_action :edit, :to => :update

So erhalten beispielsweise "autorisieren!: Anzeigen, @ post und autorisieren!: Lesen, @ post` das gleiche Ergebnis. cf. Action Aliases - cancancan

load_and_authorize_resource kann in zwei Teile unterteilt werden, load_resource und authorize_resource. Im obigen Beispiel ist "@post = Post.find (params [: post_id])" in "load_resource" "before_action" und "authorize_resource" ist "authorize!: Show, @ post" in "before_action". `Wird hinzugefügt. cf. Authorizing controller actions - cancancan

API-basierte Steuerung

Dies ist das Hauptthema. Angenommen, Sie haben im Post-Controller zwei Aktionen definiert: "show" und "update".

class PostsController < ApplicationController

  def show  # GET /posts/:post_API zum Aufrufen nach ID
  end

  def update  # PUT /posts/:post_API zum Aufrufen nach ID
  end
end

Ermöglicht dem Administrator, sowohl "GET / posts /: post_id" als auch "PUT / posts /: post_id" auszuführen, und anderen Benutzern, nur "GET / posts /: post_id" auszuführen.

Definition der Fähigkeit

class Ability
  include CanCan::Ability

  def initialize(user)
    can :show, :post  # GET /posts/:post_id kann von jedem ausgeführt werden

    if user.admin?  #Definieren Sie zusätzliche Berechtigungen für den Administrator
      can :update, :post  # PUT /posts/:post_Die ID kann nur vom Administrator ausgeführt werden
    end
  end
end

Bestätigung der Autorität

Der Zweck besteht darin, die Ausführung der API zu steuern. Wenden Sie sich daher an den Controller und nicht an die Ansicht.

class PostsController < ApplicationController

  authorize_resource class: false

  def show  # GET /posts/:post_API, die auf der ID ausgeführt werden soll
    # before_Führen Sie die folgenden Schritte in Aktion aus
    # authorize! :show, :post
  end

  def update  # PUT /posts/:post_API, die auf der ID ausgeführt werden soll
    # before_Führen Sie die folgenden Schritte in Aktion aus
    # authorize! :update, :post
  end
end

Der Schlüssel ist die Verwendung von "authorize_resource class: false" anstelle von "load_and_authorize_resource".

Gründe für die Verwendung der Klasse "authorize_resource: false"

Betrachtet man den Fall von "show" von "PostsController" als Beispiel, scheint "authorize_resource" "before_action" hinzuzufügen, was mit der folgenden Logik funktioniert. (Ich habe die Quelle nicht richtig verfolgt, daher kann es genau anders sein.)

if @Ist eine Ressource zum Posten zugewiesen?
  authorize! :show, @post
elsif 'class: false'Ist nicht angegeben?
  authorize! :show, Post
else
  authorize! :show, :post
end

Wenn Sie "load_and_authorize_resource" verwenden, wird die Ressource in "@ post" abgelegt, sodass die Berechtigungsprüfung von "@ post" ausgeführt wird. Wenn Sie nicht "class: false" angeben, wird die Berechtigungsprüfung für das Modell "Post" ausgeführt. Deshalb verwenden wir die Klasse "authorize_resource: false".

abschließend

Ich habe online nach einer Methode zum Verwalten der Ausführungsberechtigung der API gesucht, konnte aber nichts anderes finden und habe sie diesmal zusammengefasst. Wenn Sie Fehler haben, können Sie diese gerne kommentieren.

Ich denke, dass diese Anforderungen mit der Popularität von Mikrodiensten zunehmen werden. Wenn Sie sich in einer ähnlichen Situation befinden, würde ich es begrüßen, wenn Sie sich darauf beziehen könnten.