Controlling access to custom keys with custom-keys.cfg
Introduction
By default users are granted access to read and edit keys that are unknown to Funnelback. This allows for the creation of custom keys in freemarker search templates and groovy scripts without needing an administrator to grant the user access to those keys. In some cases custom keys can become options which require special permissions. In this case, Funnelback should be made aware of the options by specifying them in:
$SEARCH_HOME/conf/custom-keys.cfg
Format
The file expects one pattern per line and expects comments to be lines which start with #.
The patterns can either match the key exactly or it may have wildcards represented by '*'. Wildcards should be either:
- at the start of the key (e.g.
*.example) - at the end of a key (e.g.
example.*) - surrounded by dots (e.g.
example.*.key)
Multiple wildcards are allowed, as long as they are not adjacent to each other. For example facet.*.to.* would match the key facet.author.to.foo. However, the pattern foo.*.* is not allowed as the wildcards are adjacent.
Patterns are divided up by dots and the sections between the dot can either be a wildcard * or a literal e.g. foo. A wildcard matches any value until the next literal value in the pattern is encountered, or if the wildcard is at the end, the end of the key. For example:
| Pattern | Key | Matches | Reason |
|---|---|---|---|
| a.b | a.b | yes | |
| a.b | a | no | |
| a.* | a.b.c | yes | The wildcard is at the end and so matches b.c. |
| a.*.c.* | a.b.c.d.e.f.g | yes | The first wildcard matches b and the second matches d.e.f.g. |
| a.*.c.d | a.foo.jpg.c.d | yes | The wildcard matches foo.jpg. |
| a.*.c.d | a.main.c.c.d | no | The wildcard matches main, it does not match main.c as it stops matching at the first literal after the wildcard. After this the rest of the pattern c.d does not match the rest of the key .c.c.d. |
Example
# Specifies options which would be dangerous to give out to all users.
# Users and roles can be granted permission to edit keys defined in
# this file by setting the appropriate read.<key> or write.<key> in
# their user/role.ini files or through the UI similar to existing keys
# that Funnelback knows about.
#
# Prevent access to the 'remove-all' key
remove-all
# Prevent access to 'stencils.locks' type keys.
# Prevent access to the specific key
stencils.locks
# Also prevent access to all keys under it like 'stencils.locks.alpha'
# and 'stencils.locks.alpha.beta'
stencils.locks.*