cbSecurity
CommunitySlackSupport
v3.x
v3.x
  • 🔏Introduction
    • Release History
      • What's New With 3.4.0
      • What's New With 3.3.0
      • What's New With 3.2.0
      • What's New With 3.1.0
      • What's New With 3.0.0
    • Upgrade to 3.0.0
    • About This Book
      • Author
  • Getting Started
    • Installation
    • Overview
    • Configuration
      • 🔏Authentication
      • 🥸Basic Auth
      • 🙈CSRF
      • 🌐JWT
      • 🧱Firewall
        • DB Rules
        • JSON Rules
        • Model Rules
        • XML Rules
      • ☢️Security Headers
      • 🔬Visualizer
  • Usage
    • Authentication Services
    • Basic Authentication
    • Security Rules
    • Security Annotations
    • cbSecurity Model
      • Authentication Methods
      • Authorization Contexts
      • Blocking Methods
      • Securing Views
      • Utility Methods
      • Verification Methods
    • Secured URL
    • Interceptions
    • Cross Site Request Forgery
    • Delegates
    • Auth User
  • Security Validators
    • Auth Validator
    • BasicAuth Validator
    • CFML Security Validator
    • Custom Validator
  • JWT
    • JWT Services
    • JWT Validator
    • Refresh Tokens
    • Token Storage
    • JWT Interceptions
  • External links
    • Issue Tracker
    • Source code
    • Sponsor Us
Powered by GitBook
On this page
  • Secure Annotation
  • Authorization Context
  • Cascading Security

Was this helpful?

Edit on GitHub
Export as PDF
  1. Usage

Security Annotations

Security annotations are used to secure your handler and/or handler actions

PreviousSecurity RulesNextcbSecurity Model

Last updated 2 years ago

Was this helpful?

CBSecurity also allows you to secure your events via annotations instead of security rules. The setting that controls this security feature is called handlerAnnotationSecurity , which can be set in the

The security module has a tiered approach to annotation security as it will check the handler component first and then the requested action method second. You can apply different security contexts to each level as you see fit.

Please note that the security rules will be run first, and annotations second.

See the diagram below for inspecting security based on annotations:

Secure Annotation

The firewall will inspect handlers for a secured annotation. This annotation can be added to the entire handler or to an action method, or both. The default value of the secured annotation is a Boolean true. This means we need a user to be authenticated to access the action.

// Secure the entire handler
component {

	function index(event,rc,prc){}
	function list(event,rc,prc){}

}
// Same as this
component secured=true{
}

// Do NOT secure the handler
component secured=false{
}
// Same as this, no annotation!
component{

	function index(event,rc,prc) secured{
	}

	function list(event,rc,prc) secured="list"{

	}
	
}

Authorization Context

You can also give the annotation a value, which can be anything you like: A list of roles, a role, a list of permissions, metadata, JSON, etc. Whatever it is, this is called the authorization context, and the user validator must be able to authenticate and authorize the context, or an invalid authorization will occur.

// Secure this handler
component secured="admin,users"{

	function index(event,rc,prc) secured="list"{

	}
	
	function save(event,rc,prc) secured="write"{

	}

}

The secured value will be passed to the validator for authorization.

Cascading Security

By having the ability to annotate the handler and also the action, you create a cascading security model where they need to be able to access the handler first, and only then will the action be evaluated for access as well.

configuration section.
Annotation based security