Many cloud services require keys of one sort or another to authenticate and authorize access. Some of these use standardized authorization systems like OAuth and others use custom developer key schemes. Managing and using keys inside rulesets is a critical feature in KRL.

One of the primary reasons for having explicit support for keys in KRL is to promote code sharing. When you share a ruleset with others, you’d rather not have your keys—vital secrets—exposed. Redacting them each time you share the ruleset is a hassle. By explicitly supporting keys in the language, KRL can automatically redact keys.

Keys are declared in the meta section of the ruleset using the key pragma like so:

key errorstack "dakdladaoadoajdoa" 

This creates a key called errorstack with the value shown. Many times, there is more than one key that a service needs. You can also supply a map of name-value pairs for the key values:

key twitter {
  "consumer_key" : "skfjldfajsdkfaj", 
  "consumer_secret" : "fjfoiasjf;asdfjdoifjsdopfasdjfoa"
} 

This creates a key named twitter that has the value shown in the map.

Some libraries (like the twitter library) require keys that have specific names and values. When you aren’t working with a library that has specific requirements, you will likely need to access the keys to send them to the cloud service you’re working with. You can access keys stored in the meta section from within KRL expressions using the following syntax:

keys:<keyname>(<name>)

The <keyname> is the name given after the keyword key in the meta section. The <name> is optional. If it’s missing the entire value is returned. If it’s present, just the value associated with <name> in the map is returned (assuming the value is a map).

The following KRL declaration would bind the entire map associate with the twitter key to the variable my_key:

pre{
  my_key = keys:twitter();
}

On the other hand, the following KRL declaration would only bind the value associated with the name consumer_secret to the variable my_key:

pre{
  my_key = keys:twitter("consumer_secret");
}

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.