...
Code Block | ||||
---|---|---|---|---|
| ||||
pre{ my_key = keys:twitter("consumer_secret"); } |
Key Modules
KRL provides a mechanism for storing keys in modules that can only be accessed by named rulesets. A key module uses the pragma provide keys
to specify which previously defined keys should be made available. For example, is rulesets a16x175
and b16x77
require the use of a set of Dropbox keys, the following module could provide those keys specifically to the named rulesets:
Code Block | ||||
---|---|---|---|---|
| ||||
ruleset b16x5 {
meta {
name "Dropbox keys"
description <<
These are the keys for testing. This file should not be on a publicly available URL
>>
key dropbox {
"app_key" : "<app key here>",
"app_secret" : "<app secret here>"
}
provide keys dropbox to a16x175, b16x77
}
} |
The rulesets using the keys would load this module as usual and use the keys it provides as usual:
Code Block | ||||
---|---|---|---|---|
| ||||
ruleset a16x175 {
meta {
name "Dropbox module test"
use module b16x5
use module b16x0 alias dropbox with
app_key = keys:dropbox('app_key') and
app_secret = keys:dropbox('app_secret')
} |
This example loads the keys in module b16x5
and then uses them to configure module b16x0
.
Security Considerations
KRE tries to ensure that key values are not disclosed outside of your program. Therefore, you should be careful binding key values to variables since those values may be exposed in logging statements or any generated JavaScript.
When using key modules as shown above, you will need your key rulesets to be available on a URL so that you can register them with the rules engine. Otherwise they will not be available for use by other rulesets. The URL should be protected so that it is not publicly viewable. For example, the ruleset could be on a WebDAV server with an appropriately formatted BASIC AUTH URL or in a private Github repository.