{"_id":"57727da25617b117009e644c","githubsync":"","project":"576ebdb79c84a31900958aba","parentDoc":null,"user":"576ebd239c84a31900958ab9","__v":15,"category":{"_id":"576ec7b7560eef0e00cd3096","version":"576ebdb79c84a31900958abd","__v":0,"project":"576ebdb79c84a31900958aba","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-06-25T18:04:39.266Z","from_sync":false,"order":3,"slug":"deployment","title":"Basics"},"version":{"_id":"576ebdb79c84a31900958abd","project":"576ebdb79c84a31900958aba","__v":10,"createdAt":"2016-06-25T17:21:59.854Z","releaseDate":"2016-06-25T17:21:59.854Z","categories":["576ebdb79c84a31900958abe","576ebfc59c84a31900958ac4","576ec32f52f96619007cfb9a","576ec7b7560eef0e00cd3096","576ed4249c84a31900958add","576ed429560eef0e00cd30a3","576ed43a52f96619007cfbb5","576ed44d5a8c72170082b794","577212f20da40019004f0816","57725c7e0a6d610e00de9e4c"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"3.3.0","version":"3.3"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-06-28T13:37:38.038Z","link_external":false,"link_url":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":5,"body":"Authorization Component gives you the ability to create custom ACL metrics which is unique to each of your extension/application.\n\nIn most other solutions, you are either restrict to file based configuration for ACL or only allow to define a single metric for your entire application. This simplicity would later become an issue depends on how many extensions do you have within your application.\n\n### Basic Concept of RBAC\n\nBefore we begin let look at the basic concept of RBAC with Orchestra Platform.\n[block:parameters]\n{\n  \"data\": {\n    \"h-0\": \"Name\",\n    \"h-1\": \"Description\",\n    \"0-0\": \"actions\",\n    \"0-1\": \"Actions is either route or activity that we as a user can do (or not do).\",\n    \"1-0\": \"roles\",\n    \"1-1\": \"Roles are user group that a user can belong to.\",\n    \"2-0\": \"acl\",\n    \"2-1\": \"Is a boolean mapping between actions and roles, which determine whether a role is allow to do an action.\"\n  },\n  \"cols\": 2,\n  \"rows\": 3\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Default Authorization Driver\"\n}\n[/block]\nFor Orchestra Platform, an instance of `Orchestra\\Authorization\\Authorization` is always created to authorise the user. You can retrieve the instance via:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<?php\\n\\n\\nuse Orchestra\\\\Support\\\\Facades\\\\ACL;\\nuse Orchestra\\\\Support\\\\Facades\\\\Foundation;\\n\\n$acl = Foundation::acl();\\n\\n# or using the container.\\n\\n$acl = app('orchestra.platform.acl');\\n\\n# or via the ACL facade.\\n\\n$acl = ACL::make('orchestra')->makeOrFallback();\",\n      \"language\": \"php\"\n    }\n  ]\n}\n[/block]\n\n[block:callout]\n{\n  \"type\": \"warning\",\n  \"title\": \"Make or Fallback\",\n  \"body\": \"`makeOrFallback()` would actually use the database storage when the application installed or fallback to use runtime handler when the application is yet to be installed.\"\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Verifying an Authorization\"\n}\n[/block]\nAs an example, when accessing the User Management page Orchestra Platform will make the following authorization check:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<?php\\n\\nuse Orchestra\\\\Support\\\\Facades\\\\Foundation;\\n\\nabort_unless(Foundation::acl()->can('manage user'), 401);\",\n      \"language\": \"php\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Adding Additional Actions\"\n}\n[/block]\nAside from the default actions available you can always add new actions and set the permission:\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<?php\\n\\nuse Orchestra\\\\Model\\\\Role;\\nuse Orchestra\\\\Support\\\\Facades\\\\Foundation;\\n\\n$acl = Foundation::acl();\\n\\n// Attach 'View Dashboard' action.\\n$acl->actions()->attach(['View Dashboard']);\\n\\n// Allow admin to access 'View Dashboard'.\\n$acl->allow(Role::admin()->name, ['View Dashboard']);\\n\\n// Deny member to access 'View Dashboard'.\\n$acl->deny(Role::member()->name, ['View Dashboard']);\",\n      \"language\": \"php\"\n    }\n  ]\n}\n[/block]\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Creating Custom Authorization Driver\"\n}\n[/block]\nIt's sometime common for an extension to have custom authorization driver. This would allow each driver to have a clear separation of actions making it much easier to manage or control.\n\nImagine we have a `acme` extension, the configuration below is all you need in your extension/application service provider.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<?php\\n\\nuse Orchestra\\\\Support\\\\Facades\\\\ACL;\\n\\n$acl = ACL::make('acme');\",\n      \"language\": \"php\"\n    }\n  ]\n}\n[/block]\nWith just `ACL::make()` you can start building authorization for your application. However on every request you need to define the authorization schema and it's not dynamic (can't configured via the GUI since everything is hard-coded).\n\nTo solve this, you can integrate with the Memory Component to allow a persistent storage of the ACL metric.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"<?php\\n\\nuse Orchestra\\\\Support\\\\Facades\\\\ACL;\\nuse Orchestra\\\\Support\\\\Facades\\\\Foundation;\\n\\n$acl = ACL::make('acme')->attach(Foundation::memory());\",\n      \"language\": \"php\"\n    }\n  ]\n}\n[/block]","excerpt":"","slug":"authorization","type":"basic","title":"Authorization"}
Authorization Component gives you the ability to create custom ACL metrics which is unique to each of your extension/application. In most other solutions, you are either restrict to file based configuration for ACL or only allow to define a single metric for your entire application. This simplicity would later become an issue depends on how many extensions do you have within your application. ### Basic Concept of RBAC Before we begin let look at the basic concept of RBAC with Orchestra Platform. [block:parameters] { "data": { "h-0": "Name", "h-1": "Description", "0-0": "actions", "0-1": "Actions is either route or activity that we as a user can do (or not do).", "1-0": "roles", "1-1": "Roles are user group that a user can belong to.", "2-0": "acl", "2-1": "Is a boolean mapping between actions and roles, which determine whether a role is allow to do an action." }, "cols": 2, "rows": 3 } [/block] [block:api-header] { "type": "basic", "title": "Default Authorization Driver" } [/block] For Orchestra Platform, an instance of `Orchestra\Authorization\Authorization` is always created to authorise the user. You can retrieve the instance via: [block:code] { "codes": [ { "code": "<?php\n\n\nuse Orchestra\\Support\\Facades\\ACL;\nuse Orchestra\\Support\\Facades\\Foundation;\n\n$acl = Foundation::acl();\n\n# or using the container.\n\n$acl = app('orchestra.platform.acl');\n\n# or via the ACL facade.\n\n$acl = ACL::make('orchestra')->makeOrFallback();", "language": "php" } ] } [/block] [block:callout] { "type": "warning", "title": "Make or Fallback", "body": "`makeOrFallback()` would actually use the database storage when the application installed or fallback to use runtime handler when the application is yet to be installed." } [/block] [block:api-header] { "type": "basic", "title": "Verifying an Authorization" } [/block] As an example, when accessing the User Management page Orchestra Platform will make the following authorization check: [block:code] { "codes": [ { "code": "<?php\n\nuse Orchestra\\Support\\Facades\\Foundation;\n\nabort_unless(Foundation::acl()->can('manage user'), 401);", "language": "php" } ] } [/block] [block:api-header] { "type": "basic", "title": "Adding Additional Actions" } [/block] Aside from the default actions available you can always add new actions and set the permission: [block:code] { "codes": [ { "code": "<?php\n\nuse Orchestra\\Model\\Role;\nuse Orchestra\\Support\\Facades\\Foundation;\n\n$acl = Foundation::acl();\n\n// Attach 'View Dashboard' action.\n$acl->actions()->attach(['View Dashboard']);\n\n// Allow admin to access 'View Dashboard'.\n$acl->allow(Role::admin()->name, ['View Dashboard']);\n\n// Deny member to access 'View Dashboard'.\n$acl->deny(Role::member()->name, ['View Dashboard']);", "language": "php" } ] } [/block] [block:api-header] { "type": "basic", "title": "Creating Custom Authorization Driver" } [/block] It's sometime common for an extension to have custom authorization driver. This would allow each driver to have a clear separation of actions making it much easier to manage or control. Imagine we have a `acme` extension, the configuration below is all you need in your extension/application service provider. [block:code] { "codes": [ { "code": "<?php\n\nuse Orchestra\\Support\\Facades\\ACL;\n\n$acl = ACL::make('acme');", "language": "php" } ] } [/block] With just `ACL::make()` you can start building authorization for your application. However on every request you need to define the authorization schema and it's not dynamic (can't configured via the GUI since everything is hard-coded). To solve this, you can integrate with the Memory Component to allow a persistent storage of the ACL metric. [block:code] { "codes": [ { "code": "<?php\n\nuse Orchestra\\Support\\Facades\\ACL;\nuse Orchestra\\Support\\Facades\\Foundation;\n\n$acl = ACL::make('acme')->attach(Foundation::memory());", "language": "php" } ] } [/block]