[RAILS] Schienenbehörde / Rollenerhebung

Überblick

Ein Memo bei der Untersuchung, wie Rollen und Zugriffsrechte in Rails verwaltet werden

Zugriffsberechtigungsprüfung (Autorisierung)

・ Cancancan ・ Pundit ・ Banken

Über die Autorisierung

Die Einstellungsdatei scheint einfach zu sein und Experten oder Banken, die mit Ruby geschrieben werden können, scheinen einfach zu sein. In Bezug auf die Popularität, Experte. Wenn man sich jedoch die Folie von banken ansieht, scheint banken gut zu sein, weil "der Schöpfer die Unzufriedenheitspunkte von Krebs und Experten beseitigt hat".

Rolleneinstellung (Autoritätsverwaltung)

・ Rolify

Eine Übersicht über jeden Edelstein wird später gegeben.

Von jedem Edelstein

• Die folgenden Folien erleichtern das Verständnis des Unterschieds zwischen Cancancan, Pandit und Banken. https://speakerdeck.com/kyuden/rails-authorization

• Das Folgende ist eine Referenz zum Vergleichen von Cancancan und Pudit. https://www.icare.jpn.com/dev_cat/pundit%E3%81%A8cancancan%E3%81%AE%E6%AF%94%E8%BC%83/

Zum Festlegen der Rolle (Autorität)

1. Wenn es nur eine Rolle pro Benutzer gibt, scheint es ausreichend zu sein, diese mit enum in der Benutzertabelle zu haben. (Rolify ist in Ordnung)
2. Wenn Sie mehrere Einstellungen vornehmen möchten, scheint es einfach zu sein, rolify zu verwenden.
3. Wenn die Rollentabelle auch zusätzliche Informationen wie den japanischen Namen enthält, erstellen Sie Ihren eigenen Rollenmaster und Ihre eigene Zuordnungstabelle?

Ich sehe die Beschreibung, dass Zauberei für die Authentifizierung einfacher anzupassen ist, daher denke ich, dass Zauberei als Allzweckvorlage sicherer ist.

Damit Zertifizierung: Zauberei Autorisierung: bunken (oder pundit) Autorisierung: rolify oder original

Das Bild scheint ein allgemeiner Zweck zu sein.

Es fühlt sich ähnlich an wie die Struktur des Gunosy-Blogs unten oder wird gezogen

https://tech.gunosy.io/entry/gunosy-admin-rails

Übersicht über jeden Edelstein

Krebs (DL-Nummer: 22.394.057)

https://github.com/CanCanCommunity/cancancan

Was du tun kannst -Permissionsbedingungen können in einer Fähigkeitsklassendatei nach Modell + Aktion für jede Autorität definiert werden.

Grundlegende Verwendung -Erstelle eine Fähigkeitsklasse und schreibe sie in dein eigenes DSL. -Die grundlegende Schreibweise lautet "Name, Modell, Zustand der Aktion kann / kann nicht".

  def initialize(user)
    can :read, Post, public: true

    if user.present?  
      can :read, Post, user_id: user.id
      
      if user.admin?  
        can :read, Post
      end
    end
  end

Fehler ・ Für die ursprüngliche Notation fallen Lernkosten an

• Grundsätzlich ist die Berechtigung * can / canont für jedes Modell in einer Fähigkeitsdatei geschrieben, sodass das Wachstum einfach ist. Wenn es viele bedingte Zweige gibt, sind die Aussichten schlechter.

Referenz-URL https://qiita.com/senou/items/e28ff548e93ad0eeed3f https://qiita.com/naoki85/items/266c8d7ab469cc6ab1fe https://qiita.com/umanoda/items/679419ce30d1996628ed https://happy-teeth.hatenablog.com/entry/2018/12/09/002905

Experte (DL-Nummer: 20.682.033)

https://github.com/varvet/pundit Was du tun kannst -Sie können für jedes Modell eine Richtlinienklasse erstellen und Berechtigungsbedingungen für den Aktionsnamen definieren. ・ Kann mit Rubin geschrieben werden. ・ * Einem Modell kann nur eine Richtlinie zugeordnet werden. Wenn auf dasselbe Modell in der API und auf dem normalen Bildschirm verwiesen wird, wird es in einer Richtliniendatei beschrieben.

Grundlegende Verwendung

• Erstellen Sie für jedes Modell eine Richtliniendatei.
• Schreiben Sie eine Funktion zur Zustandsbeurteilung in die Richtliniendatei.
• Wenn Sie es verwenden, führen Sie die Autorisierung vom Controller usw. aus, um das Beurteilungsergebnis zu erhalten und es zu kontrollieren.

Fehler -Nur eine Definition wird auf Modell + Aktionsname angewendet. Wenn das Steuerelement zwischen dem Bildschirmcontroller und dem API-Controller getrennt ist, scheint es nutzlos zu sein, wenn die Aktionsnamen dupliziert werden.

Referenz-URL https://qiita.com/senou/items/e28ff548e93ad0eeed3f

banken (DL-Nummer: 285.710)

https://github.com/kyuden/banken

Was du tun kannst Die Einschränkung, dass "das Modell und die Richtlinie eins zu eins sein müssen" in pundit, wird aufgehoben, und die Autorisierungsbedingungen für Action können für jeden Controller beschrieben werden.

Grundlegende Verwendung

• Erstellen Sie eine Loyalitätsdatei für jeden Controller.
• Geben Sie die Berechtigungsbedingungen für jeden Aktionsnamen ein und führen Sie die Berechtigung auf der Controllerseite aus, um eine Beurteilung vorzunehmen.

Fehler ・ Die Anzahl der Benutzer ist geringer als die von Experten und Cancancan. ・ Im Vergleich zu Experten gibt es keine Scope-Funktion

Referenz-URL Folienfreigabe https://speakerdeck.com/kyuden/rails-authorization https://github.com/kyuden/banken Japanisches Dokument

Rolify (DL-Nummer: 6.307.168) (Juwel der Autoritätseinstellung)

https://github.com/RolifyCommunity/rolify

Was du tun kannst Die Rolle kann dem für die Authentifizierung verwendeten Modell zugeordnet werden, z. B. Benutzer. Ein Modell und eine Methode für die Rolle werden generiert. Ein Juwel für die Erteilung von Befugnissen, nicht der Genehmigungsmechanismus in der vorherigen Phase. Die Rolle kann für einen Benutzer mehrmals festgelegt werden.

Grundlegende Verwendung

• Legen Sie beim Erstellen eines Benutzers mit add_role () eine bestimmte Rolle fest.
• Ob der Benutzer über bestimmte Berechtigungen verfügt, kann mit user.has_role abgerufen werden (). Überprüfen Sie daher die Rolle dort. Die resultierende Zugriffskontrolle wird mit cancancan oder pundit eingestellt.

Referenz-URL https://qiita.com/tatsurou313/items/0f632887d049e9503e3b https://github.com/RolifyCommunity/rolify

andere

Es gibt auch eine klare Chnce- und Auth-Logik für die Authentifizierung, die jedoch weggelassen wird.