digbang / security
Security package for Laravel projects in Digbang.
Installs: 43 840
Dependents: 0
Suggesters: 0
Security: 0
Stars: 4
Watchers: 39
Forks: 3
Open Issues: 0
Requires
- php: ^8.0.2
- cartalyst/sentinel: dev-master
- illuminate/contracts: ^9.0
- illuminate/cookie: ^9.0
- illuminate/events: ^9.0
- illuminate/routing: ^9.0
- illuminate/support: ^9.0
- laravel-doctrine/fluent: ^1.3
- laravel-doctrine/orm: ^1.8
Requires (Dev)
- laravel/pint: ^0.2.1
- phpspec/phpspec: dev-main
- phpstan/phpstan: ^1.8
- phpunit/phpunit: ^9.5
- dev-master
- v6.0.3
- v6.0.2
- v6.0.1
- v6.0.0
- v5.6.3
- v5.6.2
- v5.6.1
- v5.6.0
- v5.5.3
- v5.5.2
- v5.5.1
- v5.5.0
- v5.4.1
- v5.4.0
- v5.3.2
- v5.3.1
- v5.3.0
- v5.2.6
- v5.2.5
- v5.2.4
- v5.2.3
- v5.2.2
- v5.2.1
- v5.2.0
- v5.1.10
- v5.1.9
- v5.1.8
- v5.1.7
- v5.1.6
- v5.1.5
- v5.1.4
- v5.1.3
- v5.1.2
- v5.1.1
- v5.1.0
- v5.0.7
- v5.0.6
- v5.0.5
- v5.0.4
- 5.0.3
- 5.0.2
- 5.0.1
- 5.0.0
- 4.2.4
- 4.2.3
- 4.2.2
- 4.2.1
- 4.2.0
- 4.1.7
- 4.1.6
- 4.1.5
- 4.1.4
- 4.1.3
- 4.1.2
- 4.1.1
- 4.1.0
- 4.0.5
- 4.0.4
- 4.0.3
- 4.0.2
- 4.0.1
- 4.0.0
- 3.0.1
- 3.0.0
- 2.1.3
- 2.1.2
- 2.1.1
- 2.1.0
- 2.0.6
- 2.0.5
- 2.0.4
- 2.0.3
- 2.0.2
- 2.0.1
- 2.0.0
- 1.2.4
- 1.2.3
- 1.2.2
- 1.2.1
- 1.2.0
- 1.1.6
- 1.1.5
- 1.1.4
- 1.1.3
- 1.1.2
- 1.1.1
- 1.1.0
- 1.0.3
- 1.0.2
- 1.0.1
- 1.0.0
This package is auto-updated.
Last update: 2024-10-29 04:53:05 UTC
README
Security package for new laravel projects.
Usage
Add the SecurityServiceProvider
to your config/app.php
file:
'providers' => [ Digbang\Security\Laravel\SecurityServiceProvider::class, ];
To use this package, you need to define a Context which you need to secure. URLs inside this
Context will have access to the SecurityApi
configured for them.
This way, you may have multiple Contexts running on a single application.
Add as many contexts as you need in a ServiceProvider :: boot()
of your own:
<?php namespace App\Providers; use Digbang\Security\SecurityContext; use Digbang\Security\Configurations\SecurityContextConfiguration; class MyServiceProvider extends \Illuminate\Support\ServiceProvider { public function boot(SecurityContext $securityContext) { $configuration = new SecurityContextConfiguration('ecommerce'); // customize the configuration object as needed... $securityContext->add($configuration); } }
And then refer to this context in your routing (as a route middleware):
<?php $router->group(['middleware' => 'security:ecommerce'], function(Router $router){ // Controllers inside this routing group will be able to ask for an instance // of the Digbang\Security\Contracts\SecurityApi interface. $router->get('/', ['as' => 'foo', 'uses' => 'FooController@index']); });
The Digbang\Security\Contracts\SecurityApi
interface gives access to all of this package's
functionality. In most cases, it works as a wrapper of the Cartalyst\Sentinel\Sentinel
object.
Refer to the documentation in each method to understand its uses.
Users
Basic authentication functionality is accessible directly through the SecurityApi
object.
To access the UserRepository
object, call $securityApi->users()
.
Reminders
Reminders are randomly generated codes related to a user, frequently used in reset password cycles.
To access the reminders functionality, use the ReminderRepository
with $securityApi->reminders()
.
Persistences
Persistences are session and cookie tokens generated to persist a logged-in session through time.
To access the persistences functionality, use the PersistenceRepository
with $securityApi->persistences()
.
Checkpoints
Checkpoints are custom logic to be executed every time a login attempt happens. The Security package
comes with two checkpoints: Activations
and Throttles
.
Activations
The Activation checkpoint checks if a user has already activated his account every time he or she logs in.
When this check fails, a NotActivatedException
is thrown.
To access the activations functionality, use the ActivationRepository
with $securityApi->activations()
.
Throttling
The Throttling checkpoint monitors failed login attempts to prevent DDoS attacks. It logs three different types of attempts, and reacts to each of them differently:
Global
attempts: All login attempts inside the configured context will log a global attempt.IP
attempts: Attempts coming from the same IP will be logged to recognize possible attackers.User
attempts: Multiple failed logins to the same user account will be logged to identify a possible victim.
Each type of attempt has two configurations:
- Thresholds (
int
orarray
): Represents the amount of attempts needed before the system is blocked. An array ofqty_attempts => block_time
can be used to block access for a given time based on the amount of failed attempts. - Interval (
int
): Represents the time (in seconds) that the system will block further attempts on this type.
You may change this configurations through the SecurityContextConfiguration
object. The defaults are:
'global' => [ 'interval' => 900, 'thresholds' => [ 10 => 1, 20 => 2, 30 => 4, 40 => 8, 50 => 16, 60 => 12 ] ], 'ip' => [ 'interval' => 900, 'thresholds' => 5 ], 'user' => [ 'interval' => 900, 'thresholds' => 5 ]
To access the throttling functionality, use the ThrottleRepository
with $securityApi->throttles()
.
Roles
Roles group users together and allow an administrator to give (or refuse) access to resources to a group of users.
Roles may be disabled through the SecurityContextConfiguration
object if not needed.
To access the roles functionality, use the RoleRepository
with $securityApi->roles()
.
Permissions
Permissions are functionality identifiers that are used to grant or deny access to parts of the system to specific users or roles.
By default, a RoutePermissionRepository
object will check available permissions by parsing the routes
action
array in search of a permission
key.
This strategy can be changed by implementing a different kind of Digbang\Security\Permissions\PermissionRepository
,
and changing the SecurityContextConfiguration
accordingly.
Permissions may also be disabled through the SecurityContextConfiguration
object if not needed.
To access the permissions functionality, use the PermissionRepository
with $securityApi->permissions()
.
Generating URLs
The PermissibleUrlGenerator
is an extension of Laravel's UrlGenerator
interface. The default
implementation, PermissionAwareUrlGenerator
, will check if the currently logged-in user has access to the
requested url and throw a Digbang\Security\Permissions\PermissionException
if he or she does not.
You may access this functionality through the $securityApi->url()
method.
Custom objects
The Security package extends the Cartalyst\Sentinel
interfaces with more functionality. By default,
an implementation of each interface (eg.: Digbang\Security\Users\User
) can be found in the same namespace
(eg.:Digbang\Security\Users\DefaultUser
.)
If you wish to use a custom implementation of any Entity
, these are the steps you have to follow:
- you must either:
- extend the repository implementation (eg.:
Digbang\Security\Users\DoctrineUserRepository
) with one of your own - or you may decide to implement the repository interface (eg.:
Digbang\Security\Users\UserRepository
) by yourself.
- extend the repository implementation (eg.:
- you must implement all the methods in the corresponding interface (eg.:
Digbang\Security\Users\User
.) - you must configure this in the
SecurityContextConfiguration
object, as shown above. - you may reuse the entity trait (eg.:
Digbang\Security\Users\UserTrait
.) - you may reuse the mapping trait (eg.:
Digbang\Security\Users\UserMappingTrait
.)