Download the PHP package kematjaya/access-control-bundle without Composer

On this page you can find all versions of the php package kematjaya/access-control-bundle. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package access-control-bundle

kematjaya/access-control-bundle

Manifest-driven RBAC for Symfony: a single YAML file declares your app's navigation menu (sections, items, icons, hrefs) and which of those items are gated behind grantable permissions on top of Symfony's own role_hierarchy. Ships a filtered, per-user navigation-menu endpoint for API-first frontends, an admin permission-matrix endpoint, and a PermissionVoter for fine-grained is_granted('notes.delete')-style checks in your own controllers.

No UI. Frontend integration (Next.js) is a separate package, @kematjaya/access-control-ui.

Pairs naturally with kematjaya/auth-bundle (any Symfony\Component\Security\Core\User\UserInterface implementation works — no custom contract needed here) but does not require it.

What it owns vs. what stays in your app

Owned by the bundle Stays in your app
Permission/RolePermission entities + tables The manifest YAML (your actual menus/pages/actions)
GET /api/permissions (admin matrix catalog) role_hierarchy in security.yaml
PUT /api/permissions/grants Enforcing specific actions: is_granted('notes.delete') in your controllers/API Platform operations
POST /api/permissions/export
GET /api/me/permissions, GET /api/me/menu
PermissionVoter, PermissionResolver
kematjaya:access-control:sync, kematjaya:access-control:export

Installation

Flex copies a starter config/permissions/default.yaml and registers the bundle. Then:

Configuration

config/packages/kematjaya_access_control.yaml (all keys optional, shown with their defaults):

The manifest

GET /api/me/menu returns this tree already filtered for the current user (role check, then permission-grant check, superuser sees everything) — your frontend renders it as-is, no client-side filtering logic needed.

key/key.action strings become permission attributes usable anywhere Symfony checks authorization: #[IsGranted('notes.delete')], is_granted('notes.delete') in a Twig/expression, or $authorizationChecker->isGranted('notes.delete') — PermissionVoter resolves these against the grants table (with the superuser bypass).

Run kematjaya:access-control:sync after editing the manifest to write new keys/labels into the database (existing rows never disappear automatically — it only warns about orphans, so you can decide whether to keep or manually prune them).

Endpoints

Method Path Access
GET /api/permissions superuser only — full catalog + current grants, for the admin matrix UI
PUT /api/permissions/grants superuser only — { roleCode, permissionKeys }, full replace for that role
POST /api/permissions/export superuser only — dumps the live grants to <export_dir>
GET /api/me/permissions any authenticated user — { keys: string[] } granted to their roles
GET /api/me/menu any authenticated user — filtered nav tree

None of these are wrapped in #[IsGranted]/access_control by the bundle itself (an app-level role_hierarchy config or a custom superuser_role wouldn't be visible to a hardcoded attribute) — wire your own security.yaml access_control rule for ^/api as usual; the bundle's controllers additionally self-check superuser_role where relevant.


All versions of access-control-bundle with dependencies

PHP Build Version
Package Version
Requires php Version ^8.4
doctrine/doctrine-bundle Version ^2.11|^3.0
doctrine/orm Version ^2.15|^3.0
symfony/config Version ^7.0|^8.0
symfony/dependency-injection Version ^7.0|^8.0
symfony/framework-bundle Version ^7.0|^8.0
symfony/http-foundation Version ^7.0|^8.0
symfony/http-kernel Version ^7.0|^8.0
symfony/routing Version ^7.0|^8.0
symfony/security-core Version ^7.0|^8.0
symfony/uid Version ^7.0|^8.0
symfony/yaml Version ^7.0|^8.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package kematjaya/access-control-bundle contains the following files

Loading the files please wait ...