Download the PHP package nepada/security-annotations without Composer
On this page you can find all versions of the php package nepada/security-annotations. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download nepada/security-annotations
More information about nepada/security-annotations
Files in nepada/security-annotations
Package security-annotations
Short Description Security annotations for Nette presenters and components.
License BSD-3-Clause
Informations about the package security-annotations
Security Annotations
Installation
Via Composer:
Register the extension in config.neon
:
Usage
This package builds on top of the standard access authorization of Nette components, namely Nette\Application\UI\Component::checkRequirements()
method.
This method is called before invoking any of component/presenter signal handlers, and before presenter startup
, action<>
and render<>
methods.
With this package you can specify the access rules via attributes on any of the mentioned methods, or on presenter class.
To enable this feature simple use SecurityAnnotations
trait in any presenter or component and make sure RequirementsChecker
service gets injected via injectRequirementsChecker()
- with default Nette configuration this should work on presenters out of the box, but you need to take care of components, e.g. by enabling inject calls.
Example:
The attributes and rules they enforce are completely customizable (see below), however the default setup comes with three predefined rules:
- LoggedIn - checks whether the user is logged in.
- Role("admin", "superadmin") - checks whether the user has at least one of the specified roles.
If you use
Nette\Security\Permission
as your authorizator, then role inheritance is taken into account, i.e. users that have at least one role that inherits from at least one of the specified roles are allowed as well. - Allowed(resource: "world", privilege: "destroy") - checks whether the user has at least one role that is granted the specified privilege on the specified resource.
Securing components
Properly securing components is a tricky business, take a look at the following example:
Securing presenter action<>
(or render<>
) methods is not sufficient! All it takes is a one general route in your router, e.g. a very common Route('<presenter>/<action>')
, and anyone may successfully submit the form by sending POST request to /secured/foo
URL.
You should always check user's permissions when creating the component. To make your life easier there is SecuredComponents
trait that calls the standard Nette\Application\UI\Component::checkRequirements()
method before calling the component factory (nette/application 3.2.2 and later performs this check natively, making the trait obsolete). Combining it with SecurityAnnotations
it allows you to control access to components via attributes on createComponent<>
methods.
Customizing access validators
- You can disable the default set of validators by
enableDefaultValidators: false
. - You can also define your own validators, i.e. services implementing
Nepada\SecurityAnnotations\AccessValidators\AccessValidator
interface invalidators
configuration section.
How do access validators work?
Every access validator implements Nepada\SecurityAnnotations\AccessValidators\AccessValidator
interface. The access validator specifies which attribute type it supports via its public API.
When checking the requirements PHP attributes are passed one by one to associated access validator for inspection. Based on the attribute value the validator decides either to deny access (throws Nette\Application\BadRequestException
), or grant access (no exception is thrown).
All versions of security-annotations with dependencies
nette/utils Version ^3.2@dev || ^4.0@dev
nette/component-model Version ^3.0.2@dev
nette/application Version ^3.1.4@dev
nette/security Version ^3.1@dev