{"id":13483096,"url":"https://github.com/stffn/declarative_authorization","last_synced_at":"2025-05-14T15:06:38.009Z","repository":{"id":422699,"uuid":"42626","full_name":"stffn/declarative_authorization","owner":"stffn","description":"An unmaintained authorization plugin for Rails. Please fork to support current versions of Rails","archived":false,"fork":false,"pushed_at":"2020-09-01T11:33:38.000Z","size":1045,"stargazers_count":1242,"open_issues_count":62,"forks_count":229,"subscribers_count":22,"default_branch":"master","last_synced_at":"2025-05-12T00:13:02.142Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/stffn.png","metadata":{"files":{"readme":"README.rdoc","changelog":"CHANGELOG","contributing":null,"funding":null,"license":"MIT-LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2008-08-14T14:05:37.000Z","updated_at":"2025-04-29T19:18:05.000Z","dependencies_parsed_at":"2022-08-16T10:25:11.575Z","dependency_job_id":null,"html_url":"https://github.com/stffn/declarative_authorization","commit_stats":null,"previous_names":[],"tags_count":6,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stffn%2Fdeclarative_authorization","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stffn%2Fdeclarative_authorization/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stffn%2Fdeclarative_authorization/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/stffn%2Fdeclarative_authorization/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/stffn","download_url":"https://codeload.github.com/stffn/declarative_authorization/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254169085,"owners_count":22026208,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-31T17:01:08.197Z","updated_at":"2025-05-14T15:06:37.971Z","avatar_url":"https://github.com/stffn.png","language":"Ruby","readme":"= Declarative Authorization\n\nThe declarative authorization plugin offers an authorization mechanism inspired \nby _RBAC_.  The most notable distinction to other authorization plugins is the\ndeclarative approach.  That is, authorization rules are not defined\nprogrammatically in between business logic but in an authorization configuration.\n\nWith programmatic authorization rules, the developer needs to specify which roles are\nallowed to access a specific controller action or a part of a view, which is\nnot DRY.  With a growing application code base roles' permissions often\nchange and new roles are introduced. Then, at several places of the source code\nthe changes have to be implemented, possibly leading to omissions and thus hard\nto find errors.  In these cases, a declarative approach as offered by decl_auth\nincreases the development and maintenance efficiency.\n\n\nPlugin features\n* Authorization at controller action level\n* Authorization helpers for Views\n* Authorization at model level\n  * Authorize CRUD (Create, Read, Update, Delete) activities\n  * Query rewriting to automatically only fetch authorized records\n* DSL for specifying Authorization rules in an authorization configuration\n* Support for Rails 4, with backwards compatibility through Rails 2\n\n\nRequirements\n* An authentication mechanism \n  * User object in Controller#current_user\n  * (For model security) Setting Authorization.current_user\n* User objects need to respond to a method :role_symbols that returns an\n  array of role symbols\nSee below for installation instructions.\n\n\nThere is a decl_auth screencast by Ryan Bates, nicely introducing the main concepts:\nhttp://railscasts.com/episodes/188-declarative-authorization\n\n\n= Quick Start\n\n=== Installer\n\nDeclarative Authorization comes with an installer to make setup easy.\n\nFirst, include declarative_authorization in your gemfile.\n\n    #! Gemfile\n    gem 'declarative_authorization'\n\nNext, bundle and install.\n\n    $ bundle\n    $ rails g authorization:install [UserModel=User] [field:type field:type ...] [--create-user --commit --user-belongs-to-role]\n\nThis installer will create a Role model, an admin and a user role, and set a\nhas_and_belongs_to_many relationship between the User model and the Role model.\nIt will also add a `role_symbols` method to the user model to meet\ndeclarative_authorization's requirements.  The default User model is User.  You can override this by simply typing the name of a model as above.\n\nYou can create the model with the fields provided by using the `--create-user` option.\n\nThe `--commit` option will run `rake db:migrate` and `rake db:seed`.\n\nThe `--user-belongs-to-role` option will set up a one-to-many relationship between Users and Roles.\nThat is, each user has a role_id column and can only have one role.  Role inheritance can be used\nin authorization rules.\n\nFinally, the installer also copies default authorization rules, as below.\n\n=== Generate Authorization Rules\n\nTo copy a default set of authorization rules which includes CRUD priveleges, run:\n\n    $ rails g authorization:rules\n\nThis command will copy the following to `config/authorization_rules.rb`.  Remember\nto implement the requirements of this gem as described in the Installation section\nat the end of this README if you do not use the above installer.\n\n    authorization do\n      role :guest do\n        # add permissions for guests here, e.g.\n        # has_permission_on :conferences, :to =\u003e :read\n      end\n      \n      # permissions on other roles, such as\n      # role :admin do\n      #   has_permission_on :conferences, :to =\u003e :manage\n      # end\n      # role :user do\n      #   has_permission_on :conferences, :to =\u003e [:read, :create]\n      #   has_permission_on :conferences, :to =\u003e [:update, :delete] do\n      #     if_attribute :user_id =\u003e is {user.id}\n      #   end\n      # end\n      # See the readme or GitHub for more examples\n    end\n\n    privileges do\n      # default privilege hierarchies to facilitate RESTful Rails apps\n      privilege :manage, :includes =\u003e [:create, :read, :update, :delete]\n      privilege :create, :includes =\u003e :new\n      privilege :read, :includes =\u003e [:index, :show]\n      privilege :update, :includes =\u003e :edit\n      privilege :delete, :includes =\u003e :destroy\n    end\n\n=== Controller Authorization\n\nFor RESTful controllers, add `filter_resource_access`:\n\n    class MyRestfulController \u003c ApplicationController\n      filter_resource_access\n      ...\n    end\n\nFor a non-RESTful controller, you can use `filter_access_to`:\n\n    class MyOtherController \u003c ApplicationController\n      filter_access_to :all\n      # or a group: filter_access_to [:action1, :action2]\n      ...\n    end\n\n=== View Authorization\n\nDeclarative Authorization will use `current_user` to check authorization.\n\n    \u003c%= link_to 'Edit Post', edit_post_path(@post) if permitted_to? :update, @post %\u003e\n\n\n= Authorization Data Model\n\n ----- App domain ----|-------- Authorization conf ---------|------- App domain ------\n\n                       includes                   includes\n                        .--.                        .---.\n                        |  v                        |   v\n  .------.  can_play  .------.  has_permission  .------------.  requires  .----------.\n  | User |-----------\u003e| Role |-----------------\u003e| Permission |\u003c-----------| Activity |\n  '------' *        * '------' *              * '------------' 1        * '----------'\n                                                      |\n                                              .-------+------.\n                                           1 /        | 1     \\ *\n                                 .-----------.   .---------.  .-----------.\n                                 | Privilege |   | Context |  | Attribute |\n                                 '-----------'   '---------'  '-----------'\n\nIn the application domain, each *User* may be assigned to *Roles* that should \ndefine the users' job in the application, such as _Administrator_.  On the \nright-hand side of this diagram, application developers specify which *Permissions* \nare necessary for users to perform activities, such as calling a controller action,\nviewing parts of a View or acting on records in the database.  Note that\nPermissions consist of an *Privilege* that is to be performed, such as _read_, \nand a *Context* in that the Operation takes place, such as _companies_.\n\nIn the authorization configuration, Permissions are assigned to Roles and Role\nand Permission hierarchies are defined.  *Attributes* may be employed to allow\nauthorization according to dynamic information about the context and the\ncurrent user, e.g. \"only allow access on employees that belong to the\ncurrent user's branch.\"\n\n\n= Examples\n\nA fully functional example application can be found at\nhttp://github.com/stffn/decl_auth_demo_app\n\nDetails on the demonstrated methods can be found in the API docs, either\ngenerated by yourself or at http://www.tzi.org/~sbartsch/declarative_authorization\n\n== Controller\n\nIf authentication is in place, there are two ways to enable user-specific\naccess control on controller actions.  For resource controllers, which more\nor less follow the CRUD pattern, +filter_resource_access+ is the simplest\napproach.  It sets up instance variables in before filters and calls\nfilter_access_to with the appropriate parameters to protect the CRUD methods.\n\n    class EmployeesController \u003c ApplicationController\n      filter_resource_access\n      ...\n    end\n\nSee Authorization::AuthorizationInController::ClassMethods for options on\nnested resources and custom member and collection actions.\n\nBy default, declarative_authorization will enable filter_resource_access compatibility with strong_parameters in Rails 4.  If you want to disable this behavior, you can use the `:strong_parameters` option.\n\n    class EmployeesController \u003c ApplicationController\n      filter_resource_access :strong_parameters =\u003e false\n      ...\n    end\n\nSimalarly, you can use `:strong_parameters =\u003e true` if you are using strong_parameters in Rails 3.\n\nIf you prefer less magic or your controller has no resemblance with the resource\ncontrollers, directly calling filter_access_to may be the better option.  Examples\nare given in the following.  E.g. the privilege index users is required for\naction index.  This works as a first default configuration for RESTful\ncontrollers, with these privileges easily handled in the authorization\nconfiguration, which will be described below.\n\n    class EmployeesController \u003c ApplicationController\n      filter_access_to :all\n      def index\n        ...\n      end\n      ...\n    end\n\nWhen custom actions are added to such a controller, it helps to define more\nclearly which privileges are the respective requirements.  That is when the\nfilter_access_to call may become more verbose:\n\n    class EmployeesController \u003c ApplicationController\n      filter_access_to :all\n      # this one would be included in :all, but :read seems to be\n      # a more suitable privilege than :auto_complete_for_user_name\n      filter_access_to :auto_complete_for_employee_name, :require =\u003e :read\n      def auto_complete_for_employee_name\n        ...\n      end\n      ...\n    end\n\nFor some actions it might be necessary to check certain attributes of the\nobject the action is to be acting on.  Then, the object needs to be loaded \nbefore the action's access control is evaluated.  On the other hand, some actions\nmight prefer the authorization to ignore specific attribute checks as the object is\nunknown at checking time, so attribute checks and thus automatic loading of\nobjects needs to be enabled explicitly.\n\n    class EmployeesController \u003c ApplicationController\n      filter_access_to :update, :attribute_check =\u003e true\n      def update\n        # @employee is already loaded from param[:id] because of :attribute_check\n      end\n    end\n\nYou can provide the needed object through before_filters.  This way, you have\nfull control over the object that the conditions are checked against.  Just make\nsure, your before_filters occur before any of the filter_access_to calls.\n\n    class EmployeesController \u003c ApplicationController\n      before_filter :new_employee_from_params, :only =\u003e :create\n      before_filter :new_employee, :only =\u003e [:index, :new]\n      filter_access_to :all, :attribute_check =\u003e true\n\n      def create\n        @employee.save!\n      end\n\n      protected\n      def new_employee_from_params\n        @employee = Employee.new(params[:employee])\n      end\n    end\n\nIf the access is denied, a +permission_denied+ method is called on the\ncurrent_controller, if defined, and the issue is logged.\nFor further customization of the filters and object loading, have a look at \nthe complete API documentation of filter_access_to in \nAuthorization::AuthorizationInController::ClassMethods.\n\n\n== Views\n\nIn views, a simple permitted_to? helper makes showing blocks according to the\ncurrent user's privileges easy:\n\n    \u003c% permitted_to? :create, :employees do %\u003e\n    \u003c%= link_to 'New', new_employee_path %\u003e\n    \u003c% end %\u003e\n\nOnly giving a symbol :employees as context prevents any checks of attributes\nas there is no object to check against.  For example, in case of nested resources\na new object may come in handy:\n\n    \u003c% permitted_to? :create, Branch.new(:company =\u003e @company) do\n            # or @company.branches.new\n            # or even @company.branches %\u003e\n    \u003c%= link_to 'New', new_company_branch_path(@company) %\u003e\n    \u003c% end %\u003e\n\nLists are straight-forward:\n\n    \u003c% for employee in @employees %\u003e\n    \u003c%= link_to 'Edit', edit_employee_path(employee) if permitted_to? :update, employee %\u003e\n    \u003c% end %\u003e\n\nSee also Authorization::AuthorizationHelper.\n\n\n== Models\n\nThere are two distinct features for model security built into this plugin:\nauthorizing CRUD operations on objects as well as query rewriting to limit\nresults according to certain privileges.\n\nSee also Authorization::AuthorizationInModel.\n\n=== Model security for CRUD operations\nTo activate model security, all it takes is an explicit enabling for each\nmodel that model security should be enforced on, i.e.\n\n    class Employee \u003c ActiveRecord::Base\n      using_access_control\n      ...\n    end\n\nThus,\n    Employee.create(...)\nfails, if the current user is not allowed to :create :employees according\nto the authorization rules.  For the application to find out about what \nhappened if an operation is denied, the filters throw \nAuthorization::NotAuthorized exceptions.\n\nAs access control on read are costly, with possibly lots of objects being\nloaded at a time in one query, checks on read need to be activated explicitly by\nadding the :include_read option.\n\n=== Query rewriting through named scopes\nWhen retrieving large sets of records from databases, any authorization needs\nto be integrated into the query in order to prevent inefficient filtering\nafterwards and to use LIMIT and OFFSET in SQL statements.  To keep authorization\nrules out of the source code, this plugin offers query rewriting mechanisms\nthrough named scopes.  Thus,\n\n    Employee.with_permissions_to(:read)\n\nreturns all employee records that the current user is authorized to read.  In\naddition, just like normal named scopes, query rewriting may be chained with\nthe usual find method:\n\n    Employee.with_permissions_to(:read).find(:all, :conditions =\u003e ...)\n\nIf the current user is completely missing the permissions, an \nAuthorization::NotAuthorized exception is raised.  Through \nModel.obligation_conditions, application developers may retrieve\nthe conditions for manual rewrites.\n\n\n== Authorization Rules\n\nAuthorization rules are defined in config/authorization_rules.rb\n(Or redefine rules files path via +Authorization::AUTH_DSL_FILES+).  E.g.\n\n    authorization do\n      role :admin do\n        has_permission_on :employees, :to =\u003e [:create, :read, :update, :delete]\n      end\n    end\n\nThere is a default role :+guest+ that is used if a request is not associated\nwith any user or with a user without any roles.  So, if your application has\npublic pages, :+guest+ can be used to allow access for users that are not\nlogged in.  All other roles are application defined and need to be associated\nwith users by the application.\n\nIf you need to change the default role, you can do so by adding an initializer\nthat contains the following statement:\n\n    Authorization.default_role = :anonymous\n\nPrivileges, such as :create, may be put into hierarchies to simplify\nmaintenance.  So the example above has the same meaning as\n\n    authorization do\n      role :admin do\n        has_permission_on :employees, :to =\u003e :manage\n      end\n    end\n\n    privileges do\n      privilege :manage do\n        includes :create, :read, :update, :delete\n      end\n    end\n\nPrivilege hierarchies may be context-specific, e.g. applicable to :employees.\n\n    privileges do\n      privilege :manage, :employees, :includes =\u003e :increase_salary\n    end\n\nFor more complex use cases, authorizations need to be based on attributes.  Note \nthat you then also need to set :attribute_check =\u003e true in controllers for filter_access_to.\nE.g. if a branch admin should manage only employees of his branch (see \nAuthorization::Reader in the API docs for a full list of available operators):\n\n    authorization do\n      role :branch_admin do\n        has_permission_on :employees do\n          to :manage\n          # user refers to the current_user when evaluating\n          if_attribute :branch =\u003e is {user.branch}\n        end\n      end\n    end\n\nTo reduce redundancy in has_permission_on blocks, a rule may depend on\npermissions on associated objects:\n\n    authorization do\n      role :branch_admin do\n        has_permission_on :branches, :to =\u003e :manage do\n          if_attribute :managers =\u003e contains {user}\n        end\n\n        has_permission_on :employees, :to =\u003e :manage do\n          if_permitted_to :manage, :branch\n          # instead of\n          #if_attribute :branch =\u003e {:managers =\u003e contains {user}}\n        end\n      end\n    end\n\nLastly, not only privileges may be organized in a hierarchy but roles as well.\nHere, project manager inherit the permissions of employees.\n\n      role :project_manager do\n        includes :employee\n      end\n\nSee also Authorization::Reader.\n\n== Testing\n\ndeclarative_authorization provides a few helpers to ease the testing with\nauthorization in mind.\n\nIn your test_helper.rb, to enable the helpers add\n\n    require 'declarative_authorization/maintenance'\n\n    class Test::Unit::TestCase\n      include Authorization::TestHelper\n      ...\n    end\n\nFor using the test helpers with RSpec, just add the following lines to your\nspec_helper.rb (somewhere after require 'spec/rails'):\n\n    require 'declarative_authorization/maintenance'\n    include Authorization::TestHelper\n\nNow, in unit tests, you may deactivate authorization if needed e.g. for test\nsetup and assume certain identities for tests:\n\n    class EmployeeTest \u003c ActiveSupport::TestCase\n      def test_should_read\n        without_access_control do\n          Employee.create(...)\n        end\n        assert_nothing_raised do\n          with_user(admin) do\n            Employee.find(:first)\n          end\n        end\n      end\n    end\n    \nOr, with RSpec, it would work like this:\n\n  describe Employee do\n    it \"should read\" do\n      without_access_control do\n        Employee.create(...)\n      end\n      with_user(admin) do\n        Employee.find(:first)\n      end\n    end\n  end\n\nIn functional tests, get, posts, etc. may be tested in the name of certain users:\n\n    get_with admin, :index\n    post_with admin, :update, :employee =\u003e {...}\n\nSee Authorization::TestHelper for more information.\n\n\n= Installation of declarative_authorization\n\nOne of three options to install the plugin:\n* Install by Gem:  Add to your environment.rb in the initializer block:\n    config.gem \"declarative_authorization\"\n  Note: you need gemcutter support in place, i.e. call\n    gem install gemcutter\n    gem tumble\n  And call from your application's root directory\n    rake gems:install\n* Alternativelyi, in Rails 2, to install from github, execute in your application's root directory\n    cd vendor/plugins \u0026\u0026 git clone git://github.com/stffn/declarative_authorization.git\n\nThen, \n* provide the requirements as noted below, \n* create a basic config/authorization_rules.rb--you might want to take the \n  provided example authorization_rules.dist.rb in the plugin root as a starting \n  point, \n* add +filter_access_to+, +permitted_to+? and model security as needed.\n\n== Providing the Plugin's Requirements\nThe requirements are\n* Rails \u003e= 2.2, including 3 and Ruby \u003e= 1.8.6, including 1.9\n* An authentication mechanism \n* A user object returned by Controller#current_user\n* An array of role symbols returned by User#role_symbols\n* (For model security) Setting Authorization.current_user to the request's user\n\nOf the various ways to provide these requirements, here is one way employing\nrestful_authentication.\n\n* Install restful_authentication\n   cd vendor/plugins \u0026\u0026 git clone git://github.com/technoweenie/restful-authentication.git restful_authentication\n   cd ../.. \u0026\u0026 ruby script/generate authenticated user sessions\n* Move \"include AuthenticatedSystem\" to ApplicationController\n* Add +filter_access_to+ calls as described above.\n* If you'd like to use model security, add a before_filter that sets the user \n  globally to your ApplicationController.  This is thread-safe.\n   before_filter :set_current_user\n   protected\n   def set_current_user\n     Authorization.current_user = current_user\n   end\n\n* Add roles field to the User model through a :+has_many+ association\n  (this is just one possible approach; you could just as easily use \n  :+has_many+ :+through+ or a serialized roles array):\n  * create a migration for table roles \n     class CreateRoles \u003c ActiveRecord::Migration\n       def self.up\n         create_table \"roles\" do |t|\n           t.column :title, :string\n           t.references :user\n         end\n       end\n\n       def self.down\n         drop_table \"roles\"\n       end\n     end\n\n  * create a model Role,\n     class Role \u003c ActiveRecord::Base\n       belongs_to :user\n     end\n\n  * add +has_many+ :+roles+ to the User model and a roles method that returns the roles \n    as an Array of Symbols, e.g.\n     class User \u003c ActiveRecord::Base\n       has_many :roles\n       def role_symbols\n         (roles || []).map {|r| r.title.to_sym}\n       end\n     end\n\n  * add roles to your User objects using e.g.\n     user.roles.create(:title =\u003e \"admin\")\n\nNote:  If you choose to generate an Account model for restful_authentication\ninstead of a User model as described above, you have to customize the\nexamples and create a ApplicationController#current_user method.\n\n\n== Debugging Authorization\n\nCurrently, the main means of debugging authorization decisions is logging and\nexceptions.  Denied access to actions is logged to +warn+ or +info+, including\nsome hints about what went wrong.\n\nAll bang methods throw exceptions which may be used to retrieve more\ninformation about a denied access than a Boolean value.\n\n\n== Authorization Development Support\n\nIf your authorization rules become more complex, you might be glad to use\nthe authorization rules browser that comes with declarative_authorization.\nIt has a syntax-highlighted and a graphical view with filtering of the current\nauthorization rules.\n\nBy default, it will only be available in development mode.  To use it, add\nthe following lines to your authorization_rules.rb for the appropriate role:\n\n  has_permission_on :authorization_rules, :to =\u003e :read\n\nThen, point your browser to\n  http://localhost/authorization_rules\n\nThe browser needs Rails 2.3 (for Engine support).  The graphical view requires \nGraphviz (which e.g. can be installed through the graphviz package under Debian \nand Ubuntu) and has only been tested under Linux.  Note: for Change Support\nyou'll need to have a User#login method that returns a non-ambiguous user\nname for identification.\n\n\n= Help and Contact\n\nWe have an issue tracker[http://github.com/stffn/declarative_authorization/issues]\nfor bugs and feature requests as well as a \nGoogle Group[http://groups.google.com/group/declarative_authorization] for\ndiscussions on the usage of the plugin.  You are very welcome to contribute.\nJust fork the git repository and create a new issue, send a pull request or\ncontact me personally.\n\nMaintained by\n\nSteffen Bartsch\nTZI, Universität Bremen, Germany\nsbartsch at tzi.org\n\n\n= Contributors\n\nThanks to John Joseph Bachir, Dennis Blöte, Eike Carls, Damian Caruso, Kai Chen, Erik Dahlstrand,\nJeroen van Dijk, Alexander Dobriakov, Sebastian Dyck, Ari Epstein, Jeremy Friesen,\nTim Harper, John Hawthorn, hollownest, Daniel Kristensen, Jeremy Kleindl, Joel Kociolek,\nBenjamin ter Kuile, Brad Langhorst, Brian Langenfeld,\nGeorg Ledermann, Geoff Longman, Olly Lylo, Mark Mansour, Thomas Maurer, Kevin Moore,\nTyler Pickett, Edward Rudd, Sharagoz,\nTJ Singleton, Mike Vincent, Joel Westerberg\n\n\n= License\n\nCopyright (c) 2008 Steffen Bartsch, TZI, Universität Bremen, Germany\nreleased under the MIT license\n\n","funding_links":[],"categories":["Authorization","Ruby"],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstffn%2Fdeclarative_authorization","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fstffn%2Fdeclarative_authorization","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fstffn%2Fdeclarative_authorization/lists"}