Configuration
How to configure CBSecurity
By default, the security module will register itself for you using the module configuration settings you define in the
config/ColdBox.cfc. You can create a cbsecurity key in the modulesettings or if you are in ColdBox 7 you can create a config/modules/cbsecurity.cfc as well.Here you can see how to configure CBSecurity, but you can also navigate to the different configuration sections for an in-depth overview of those settings:
config/Coldbox.cfc
1
// Module Settings
2
moduleSettings = {
3
cbauth = {
4
// This is the path to your user object that contains the credential validation methods
5
userServiceClass = ""
6
},
7
8
cbsecurity = {
9
/**
10
* --------------------------------------------------------------------------
11
* Authentication Services
12
* --------------------------------------------------------------------------
13
* Here you will configure which service is in charge of providing authentication for your application.
14
* By default we leverage the cbauth module which expects you to connect it to a database via your own User Service.
15
*
16
* Available authentication providers:
17
* - cbauth : Leverages your own UserService that determines authentication and user retrieval
18
* - basicAuth : Leverages basic authentication and basic in-memory user registration in our configuration
19
* - custom : Any other service that adheres to our IAuthService interface
20
*/
21
authentication : {
22
// The WireBox ID of the authentication service to use which must adhere to the cbsecurity.interfaces.IAuthService interface.
23
"provider" : "authenticationService@cbauth",
24
// WireBox ID of the user service to use when leveraging user authentication, we default this to whatever is set
25
// by cbauth or basic authentication. (Optional)
26
"userService" : "",
27
// The name of the variable to use to store an authenticated user in prc scope on all incoming authenticated requests
28
"prcUserVariable" : "oCurrentUser"
29
},
30
31
/**
32
* --------------------------------------------------------------------------
33
* Basic Auth
34
* --------------------------------------------------------------------------
35
* These settings are used so you can configure the hashing patterns of the user storage
36
* included with cbsecurity. These are only used if you are using the `BasicAuthUserService` as
37
* your service of choice alongside the `BasicAuthValidator`
38
*/
39
basicAuth : {
40
// Hashing algorithm to use
41
hashAlgorithm : "SHA-512",
42
// Iterates the number of times the hash is computed to create a more computationally intensive hash.
43
hashIterations : 5,
44
// User storage: The `key` is the username. The value is the user credentials that can include
45
// { roles: "", permissions : "", firstName : "", lastName : "", password : "" }
46
users : {}
47
},
48
49
/**
50
* --------------------------------------------------------------------------
51
* CSRF - Cross Site Request Forgery Settings
52
* --------------------------------------------------------------------------
53
* These settings configures the cbcsrf module. Look at the module configuration for more information
54
*/
55
csrf : {
56
// By default we load up an interceptor that verifies all non-GET incoming requests against the token validations
57
enableAutoVerifier : false,
58
// A list of events to exclude from csrf verification, regex allowed: e.g. stripe\..*
59
verifyExcludes : [],
60
// By default, all csrf tokens have a life-span of 30 minutes. After 30 minutes, they expire and we aut-generate new ones.
61
// If you do not want expiring tokens, then set this value to 0
62
rotationTimeout : 30,
63
// Enable the /cbcsrf/generate endpoint to generate cbcsrf tokens for secured users.
64
enableEndpoint : false,
65
// The WireBox mapping to use for the CacheStorage
66
cacheStorage : "CacheStorage@cbstorages",
67
// Enable/Disable the cbAuth login/logout listener in order to rotate keys
68
enableAuthTokenRotator : true
69
},
70
/**
71
* --------------------------------------------------------------------------
72
* Firewall Settings
73
* --------------------------------------------------------------------------
74
* The firewall is used to block/check access on incoming requests via security rules or via annotation on handler actions.
75
* Here you can configure the operation of the firewall and especially what Validator will be in charge of verifying authentication/authorization
76
* during a matched request.
77
*/
78
firewall : {
79
// Auto load the global security firewall automatically, else you can load it a-la-carte via the `Security` interceptor
80
"autoLoadFirewall" : true,
81
// The Global validator is an object that will validate the firewall rules and annotations and provide feedback on either authentication or authorization issues.
82
"validator" : "CBAuthValidator@cbsecurity",
83
// Activate handler/action based annotation security
84
"handlerAnnotationSecurity" : true,
85
// The global invalid authentication event or URI or URL to go if an invalid authentication occurs
86
"invalidAuthenticationEvent" : "",
87
// Default Auhtentication Action: override or redirect when a user has not logged in
88
"defaultAuthenticationAction" : "redirect",
89
// The global invalid authorization event or URI or URL to go if an invalid authorization occurs
90
"invalidAuthorizationEvent" : "",
91
// Default Authorization Action: override or redirect when a user does not have enough permissions to access something
92
"defaultAuthorizationAction" : "redirect",
93
// Firewall database event logs.
94
"logs" : {
95
"enabled" : false,
96
"dsn" : "",
97
"schema" : "",
98
"table" : "cbsecurity_logs",
99
"autoCreate" : true
100
},
101
// Firewall Rules, this can be a struct of detailed configuration
102
// or a simple array of inline rules
103
"rules" : {
104
// Use regular expression matching on the rule match types
105
"useRegex" : true,
106
// Force SSL for all relocations
107
"useSSL" : false,
108
// A collection of default name-value pairs to add to ALL rules
109
// This way you can add global roles, permissions, redirects, etc
110
"defaults" : {},
111
// You can store all your rules in this inline array
112
"inline" : [],
113
// If you don't store the rules inline, then you can use a provider to load the rules
114
// The source can be a json file, an xml file, model, db
115
// Each provider can have it's appropriate properties as well. Please see the documentation for each provider.
116
"provider" : { "source" : "", "properties" : {} }
117
}
118
},
119
120
/**
121
* --------------------------------------------------------------------------
122
* Security Visualizer
123
* --------------------------------------------------------------------------
124
* This is a debugging panel that when active, a developer can visualize security settings and more.
125
* You can use the `securityRule` to define what rule you want to use to secure the visualizer but make sure the `secured` flag is turned to true.
126
* You don't have to specify the `secureList` key, we will do that for you.
127
*/
128
visualizer : {
129
"enabled" : false,
130
"secured" : false,
131
"securityRule" : {}
132
},
133
134
/**
135
* --------------------------------------------------------------------------
136
* Security Headers
137
* --------------------------------------------------------------------------
138
* This section is the way to configure cbsecurity for header detection, inspection and setting for common
139
* security exploits like XSS, ClickJacking, Host Spoofing, IP Spoofing, Non SSL usage, HSTS and much more.
140
*/
141
securityHeaders : {
142
// Master switch for security headers
143
"enabled" : true,
144
// If you trust the upstream then we will check the upstream first for specific headers
145
"trustUpstream" : false,
146
// Content Security Policy
147
// Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks,
148
// including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to
149
// site defacement, to malware distribution.
150
// https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
151
"contentSecurityPolicy" : {
152
// Disabled by defautl as it is totally customizable
153
"enabled" : false,
154
// The custom policy to use, by default we don't include any
155
"policy" : ""
156
},
157
// The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in
158
// the Content-Type headers should be followed and not be changed => X-Content-Type-Options: nosniff
159
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
160
"contentTypeOptions" : { "enabled" : true },
161
"customHeaders" : {
162
// Name : value pairs as you see fit.
163
},
164
// Disable Click jacking: X-Frame-Options: DENY OR SAMEORIGIN
165
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
166
"frameOptions" : { "enabled" : true, "value" : "SAMEORIGIN" },
167
// HTTP Strict Transport Security (HSTS)
168
// The HTTP Strict-Transport-Security response header (often abbreviated as HSTS)
169
// informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it
170
// using HTTP should automatically be converted to HTTPS.
171
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security,
172
"hsts" : {
173
"enabled" : true,
174
// The time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS, 1 year is the default
175
"max-age" : "31536000",
176
// See Preloading Strict Transport Security for details. Not part of the specification.
177
"preload" : false,
178
// If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
179
"includeSubDomains" : false
180
},
181
// Validates the host or x-forwarded-host to an allowed list of valid hosts
182
"hostHeaderValidation" : {
183
"enabled" : false,
184
// Allowed hosts list
185
"allowedHosts" : ""
186
},
187
// Validates the ip address of the incoming request
188
"ipValidation" : {
189
"enabled" : false,
190
// Allowed IP list
191
"allowedIPs" : ""
192
},
193
// The Referrer-Policy HTTP header controls how much referrer information (sent with the Referer header) should be included with requests.
194
// Aside from the HTTP header, you can set this policy in HTML.
195
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
196
"referrerPolicy" : { "enabled" : true, "policy" : "same-origin" },
197
// Detect if the incoming requests are NON-SSL and if enabled, redirect with SSL
198
"secureSSLRedirects" : { "enabled" : false },
199
// Some browsers have built in support for filtering out reflected XSS attacks. Not foolproof, but it assists in XSS protection.
200
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection,
201
// X-XSS-Protection: 1; mode=block
202
"xssProtection" : { "enabled" : true, "mode" : "block" }
203
},
204
205
/**
206
* --------------------------------------------------------------------------
207
* Json Web Tokens Settings
208
* --------------------------------------------------------------------------
209
* Here you can configure the JWT services for operation and storage. In order for your firewall
210
* to leverage JWT authentication/authorization you must make sure you use the `JwtAuthValidator` as your
211
* validator of choice; either globally or at the module level.
212
*/
213
jwt : {
214
// The issuer authority for the tokens, placed in the `iss` claim
215
"issuer" : "",
216
// The jwt secret encoding key, defaults to getSystemEnv( "JWT_SECRET", "" )
217
"secretKey" : getSystemSetting( "JWT_SECRET", "" ),
218
// by default it uses the authorization bearer header, but you can also pass a custom one as well.
219
"customAuthHeader" : "x-auth-token",
220
// The expiration in minutes for the jwt tokens
221
"expiration" : 60,
222
// If true, enables refresh tokens, longer lived tokens (not implemented yet)
223
"enableRefreshTokens" : false,
224
// The default expiration for refresh tokens, defaults to 30 days
225
"refreshExpiration" : 10080,
226
// The Custom header to inspect for refresh tokens
227
"customRefreshHeader" : "x-refresh-token",
228
// If enabled, the JWT validator will inspect the request for refresh tokens and expired access tokens
229
// It will then automatically refresh them for you and return them back as
230
// response headers in the same request according to the customRefreshHeader and customAuthHeader
231
"enableAutoRefreshValidator" : false,
232
// Enable the POST > /cbsecurity/refreshtoken API endpoint
233
"enableRefreshEndpoint" : true,
234
// encryption algorithm to use, valid algorithms are: HS256, HS384, and HS512
235
"algorithm" : "HS512",
236
// Which claims neds to be present on the jwt token or `TokenInvalidException` upon verification and decoding
237
"requiredClaims" : [] ,
238
// The token storage settings
239
"tokenStorage" : {
240
// enable or not, default is true
241
"enabled" : true,
242
// A cache key prefix to use when storing the tokens
243
"keyPrefix" : "cbjwt_",
244
// The driver to use: db, cachebox or a WireBox ID
245
"driver" : "cachebox",
246
// Driver specific properties
247
"properties" : {
248
"cacheName" : "default"
249
}
250
}
251
}
252
};
In ColdBox 7 you can segregate module configurations so they are more manageable and have their own identity. Just create a
config/modules/cbsecurity.cfc with a nice configure() method:config/cmo
1
component{
2
3
function configure(){
4
return {
5
/**
6
* --------------------------------------------------------------------------
7
* Authentication Services
8
* --------------------------------------------------------------------------
9
* Here you will configure which service is in charge of providing authentication for your application.
10
* By default we leverage the cbauth module which expects you to connect it to a database via your own User Service.
11
*
12
* Available authentication providers:
13
* - cbauth : Leverages your own UserService that determines authentication and user retrieval
14
* - basicAuth : Leverages basic authentication and basic in-memory user registration in our configuration
15
* - custom : Any other service that adheres to our IAuthService interface
16
*/
17
authentication : {
18
// The WireBox ID of the authentication service to use which must adhere to the cbsecurity.interfaces.IAuthService interface.
19
"provider" : "authenticationService@cbauth",
20
// WireBox ID of the user service to use when leveraging user authentication, we default this to whatever is set
21
// by cbauth or basic authentication. (Optional)
22
"userService" : "",
23
// The name of the variable to use to store an authenticated user in prc scope on all incoming authenticated requests
24
"prcUserVariable" : "oCurrentUser"
25
},
26
27
/**
28
* --------------------------------------------------------------------------
29
* Basic Auth
30
* --------------------------------------------------------------------------
31
* These settings are used so you can configure the hashing patterns of the user storage
32
* included with cbsecurity. These are only used if you are using the `BasicAuthUserService` as
33
* your service of choice alongside the `BasicAuthValidator`
34
*/
35
basicAuth : {
36
// Hashing algorithm to use
37
hashAlgorithm : "SHA-512",
38
// Iterates the number of times the hash is computed to create a more computationally intensive hash.
39
hashIterations : 5,
40
// User storage: The `key` is the username. The value is the user credentials that can include
41
// { roles: "", permissions : "", firstName : "", lastName : "", password : "" }
42
users : {}
43
},
44
45
/**
46
* --------------------------------------------------------------------------
47
* CSRF - Cross Site Request Forgery Settings
48
* --------------------------------------------------------------------------
49
* These settings configures the cbcsrf module. Look at the module configuration for more information
50
*/
51
csrf : {
52
// By default we load up an interceptor that verifies all non-GET incoming requests against the token validations
53
enableAutoVerifier : false,
54
// A list of events to exclude from csrf verification, regex allowed: e.g. stripe\..*
55
verifyExcludes : [],
56
// By default, all csrf tokens have a life-span of 30 minutes. After 30 minutes, they expire and we aut-generate new ones.
57
// If you do not want expiring tokens, then set this value to 0
58
rotationTimeout : 30,
59
// Enable the /cbcsrf/generate endpoint to generate cbcsrf tokens for secured users.
60
enableEndpoint : false,
61
// The WireBox mapping to use for the CacheStorage
62
cacheStorage : "CacheStorage@cbstorages",
63
// Enable/Disable the cbAuth login/logout listener in order to rotate keys
64
enableAuthTokenRotator : true
65
},
66
/**
67
* --------------------------------------------------------------------------
68
* Firewall Settings
69
* --------------------------------------------------------------------------
70
* The firewall is used to block/check access on incoming requests via security rules or via annotation on handler actions.
71
* Here you can configure the operation of the firewall and especially what Validator will be in charge of verifying authentication/authorization
72
* during a matched request.
73
*/
74
firewall : {
75
// Auto load the global security firewall automatically, else you can load it a-la-carte via the `Security` interceptor
76
"autoLoadFirewall" : true,
77
// The Global validator is an object that will validate the firewall rules and annotations and provide feedback on either authentication or authorization issues.
78
"validator" : "CBAuthValidator@cbsecurity",
79
// Activate handler/action based annotation security
80
"handlerAnnotationSecurity" : true,
81
// The global invalid authentication event or URI or URL to go if an invalid authentication occurs
82
"invalidAuthenticationEvent" : "",
83
// Default Auhtentication Action: override or redirect when a user has not logged in
84
"defaultAuthenticationAction" : "redirect",
85
// The global invalid authorization event or URI or URL to go if an invalid authorization occurs
86
"invalidAuthorizationEvent" : "",
87
// Default Authorization Action: override or redirect when a user does not have enough permissions to access something
88
"defaultAuthorizationAction" : "redirect",
89
// Firewall database event logs.
90
"logs" : {
91
"enabled" : false,
92
"dsn" : "",
93
"schema" : "",
94
"table" : "cbsecurity_logs",
95
"autoCreate" : true
96
},
97
// Firewall Rules, this can be a struct of detailed configuration
98
// or a simple array of inline rules
99
"rules" : {
100
// Use regular expression matching on the rule match types
101
"useRegex" : true,
102
// Force SSL for all relocations
103
"useSSL" : false,
104
// A collection of default name-value pairs to add to ALL rules
105
// This way you can add global roles, permissions, redirects, etc
106
"defaults" : {},
107
// You can store all your rules in this inline array
108
"inline" : [],
109
// If you don't store the rules inline, then you can use a provider to load the rules
110
// The source can be a json file, an xml file, model, db
111
// Each provider can have it's appropriate properties as well. Please see the documentation for each provider.
112
"provider" : { "source" : "", "properties" : {} }
113
}
114
},
115
116
/**
117
* --------------------------------------------------------------------------
118
* Security Visualizer
119
* --------------------------------------------------------------------------
120
* This is a debugging panel that when active, a developer can visualize security settings and more.
121
* You can use the `securityRule` to define what rule you want to use to secure the visualizer but make sure the `secured` flag is turned to true.
122
* You don't have to specify the `secureList` key, we will do that for you.
123
*/
124
visualizer : {
125
"enabled" : false,
126
"secured" : false,
127
"securityRule" : {}
128
},
129
130
/**
131
* --------------------------------------------------------------------------
132
* Security Headers
133
* --------------------------------------------------------------------------
134
* This section is the way to configure cbsecurity for header detection, inspection and setting for common
135
* security exploits like XSS, ClickJacking, Host Spoofing, IP Spoofing, Non SSL usage, HSTS and much more.
136
*/
137
securityHeaders : {
138
// Master switch for security headers
139
"enabled" : true,
140
// If you trust the upstream then we will check the upstream first for specific headers
141
"trustUpstream" : false,
142
// Content Security Policy
143
// Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks,
144
// including Cross-Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft, to
145
// site defacement, to malware distribution.
146
// https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP
147
"contentSecurityPolicy" : {
148
// Disabled by defautl as it is totally customizable
149
"enabled" : false,
150
// The custom policy to use, by default we don't include any
151
"policy" : ""
152
},
153
// The X-Content-Type-Options response HTTP header is a marker used by the server to indicate that the MIME types advertised in
154
// the Content-Type headers should be followed and not be changed => X-Content-Type-Options: nosniff
155
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
156
"contentTypeOptions" : { "enabled" : true },
157
"customHeaders" : {
158
// Name : value pairs as you see fit.
159
},
160
// Disable Click jacking: X-Frame-Options: DENY OR SAMEORIGIN
161
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
162
"frameOptions" : { "enabled" : true, "value" : "SAMEORIGIN" },
163
// HTTP Strict Transport Security (HSTS)
164
// The HTTP Strict-Transport-Security response header (often abbreviated as HSTS)
165
// informs browsers that the site should only be accessed using HTTPS, and that any future attempts to access it
166
// using HTTP should automatically be converted to HTTPS.
167
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security,
168
"hsts" : {
169
"enabled" : true,
170
// The time, in seconds, that the browser should remember that a site is only to be accessed using HTTPS, 1 year is the default
171
"max-age" : "31536000",
172
// See Preloading Strict Transport Security for details. Not part of the specification.
173
"preload" : false,
174
// If this optional parameter is specified, this rule applies to all of the site's subdomains as well.
175
"includeSubDomains" : false
176
},
177
// Validates the host or x-forwarded-host to an allowed list of valid hosts
178
"hostHeaderValidation" : {
179
"enabled" : false,
180
// Allowed hosts list
181
"allowedHosts" : ""
182
},
183
// Validates the ip address of the incoming request
184
"ipValidation" : {
185
"enabled" : false,
186
// Allowed IP list
187
"allowedIPs" : ""
188
},
189
// The Referrer-Policy HTTP header controls how much referrer information (sent with the Referer header) should be included with requests.
190
// Aside from the HTTP header, you can set this policy in HTML.
191
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referrer-Policy
192
"referrerPolicy" : { "enabled" : true, "policy" : "same-origin" },
193
// Detect if the incoming requests are NON-SSL and if enabled, redirect with SSL
194
"secureSSLRedirects" : { "enabled" : false },
195
// Some browsers have built in support for filtering out reflected XSS attacks. Not foolproof, but it assists in XSS protection.
196
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection,
197
// X-XSS-Protection: 1; mode=block
198
"xssProtection" : { "enabled" : true, "mode" : "block" }
199
},
200
201
/**
202
* --------------------------------------------------------------------------
203
* Json Web Tokens Settings
204
* --------------------------------------------------------------------------
205
* Here you can configure the JWT services for operation and storage. In order for your firewall
206
* to leverage JWT authentication/authorization you must make sure you use the `JwtAuthValidator` as your
207
* validator of choice; either globally or at the module level.
208
*/
209
jwt : {
210
// The issuer authority for the tokens, placed in the `iss` claim
211
"issuer" : "",
212
// The jwt secret encoding key, defaults to getSystemEnv( "JWT_SECRET", "" )
213
"secretKey" : getSystemSetting( "JWT_SECRET", "" ),
214
// by default it uses the authorization bearer header, but you can also pass a custom one as well.
215
"customAuthHeader" : "x-auth-token",
216
// The expiration in minutes for the jwt tokens
217
"expiration" : 60,
218
// If true, enables refresh tokens, longer lived tokens (not implemented yet)
219
"enableRefreshTokens" : false,
220
// The default expiration for refresh tokens, defaults to 30 days
221
"refreshExpiration" : 10080,
222
// The Custom header to inspect for refresh tokens
223
"customRefreshHeader" : "x-refresh-token",
224
// If enabled, the JWT validator will inspect the request for refresh tokens and expired access tokens
225
// It will then automatically refresh them for you and return them back as
226
// response headers in the same request according to the customRefreshHeader and customAuthHeader
227
"enableAutoRefreshValidator" : false,
228
// Enable the POST > /cbsecurity/refreshtoken API endpoint
229
"enableRefreshEndpoint" : true,
230
// encryption algorithm to use, valid algorithms are: HS256, HS384, and HS512
231
"algorithm" : "HS512",
232
// Which claims neds to be present on the jwt token or `TokenInvalidException` upon verification and decoding
233
"requiredClaims" : [] ,
234
// The token storage settings
235
"tokenStorage" : {
236
// enable or not, default is true
237
"enabled" : true,
238
// A cache key prefix to use when storing the tokens
239
"keyPrefix" : "cbjwt_",
240
// The driver to use: db, cachebox or a WireBox ID
241
"driver" : "cachebox",
242
// Driver specific properties
243
"properties" : {
244
"cacheName" : "default"
245
}
246
}
247
};
248
}
249
}
Each module can also have its own CBSecurity settings which override or collaborate with the global settings. So what can a module do:
- Have its own validator
- Have its own security rules
- Have its own invalid authentication event and action
- Have its own invalid authorization event and action
You will create a
cbsecurity struct within the module's settings struct in the ModuleConfig.cfcmodule/ModuleConfig.cfc
settings = {
// CB Security Module Settings
cbsecurity : {
firewall : {
// Module Relocation when an invalid access is detected, instead of each rule declaring one.
"invalidAuthenticationEvent" : "api:Home.onInvalidAuth",
// Default Auhtentication Action: override or redirect when a user has not logged in
"defaultAuthenticationAction" : "override",
// Module override event when an invalid access is detected, instead of each rule declaring one.
"invalidAuthorizationEvent" : "api:Home.onInvalidAuthorization",
// Default invalid action: override or redirect when an invalid access is detected, default is to redirect
"defaultAuthorizationAction" : "override",
// The validator to use for this module
"validator" : "JWTService@cbsecurity",
// Inline rules
"rules" : [ { "secureList" : "api:Secure\.*" } ]
// Full rules
// or a simple array of inline rules
"rules" : {
// Use regular expression matching on the rule match types
"useRegex" : true,
// Force SSL for all relocations
"useSSL" : false,
// A collection of default name-value pairs to add to ALL rules
// This way you can add global roles, permissions, redirects, etc
"defaults" : {},
// You can store all your rules in this inline array
"inline" : [],
// If you don't store the rules inline, then you can use a provider to load the rules
// The source can be a json file, an xml file, model, db
// Each provider can have it's appropriate properties as well. Please see the documentation for each provider.
"provider" : { "source" : "", "properties" : {} }
}
}
}
}
Please note that a module's security rules will be PREPENDED to the global rules
Also note that if modules are loaded dynamically, it will still inspect them and register them if cbsecurity settings are found. The same goes for unloading, the entire security rules for that module will cease to exist.
Last modified 6mo ago