Is this a known bug? Following along with the HipChat example code (linked below), if I change the Background Color control-group code to what is displayed in the first code snippet below, then action.hipchat.param.color takes on the values of 1 or 0 when saving the alert action form, instead of what I'd expect to be a "Yes" or "No" string value (respectively). Excerpt of edited $SPLUNK_HOME$/etc/apps/hipchat_app/default/data/ui/alerts/hipchat.html http://docs.splunk.com/Documentation/Splunk/latest/AdvancedDev/ModAlertsAdvancedExample <div class="control-group"> <label class="control-label" for="hipchat_color">Background Color</label> <div class="controls"> <select id="hipchat_color" name="action.hipchat.param.color"> <option value="Yes">Yes</option> <option value="No">No</option> </select> <span class="help-block">Change the background of the hipchat message.</span> </div> </div> This is an issue because when I go to pull up the alert action again, it does not load the correct param (the form expects a "Yes" or "No" value, but gets a 1 or 0). As a workaround, I've had to edit the values to a 1 or 0 as such to get this to work as I expect it to: <div class="control-group"> <label class="control-label" for="hipchat_color">Background Color</label> <div class="controls"> <select id="hipchat_color" name="action.hipchat.param.color"> <option value="1">Yes</option> <option value="0">No</option> </select> <span class="help-block">Change the background of the hipchat message.</span> </div> </div> ... View more

Scenario: Let's say I have a single index (e.g., main) containing data of interest to multiple different parties/roles, and it is understood that Role1 should only see all data with type=t1 in it, Role2 should only see type=t2, and Role3 only type=t3, etc. For Role1, if I set my restrictions to the following: index=main type=t1 And a user creates a calculated field with the following definition: Apply to = source named = * Field name = type Eval expression = "t1" This user will be able to see results for all of index=main, since the user's search-time extraction of type=t1 will now be true for all sources. Question: How do I securely restrict search terms such that it cannot be circumvented by the user's search-time knowledge objects, like calculated fields? Related post (but I find the answer is not secure): https://answers.splunk.com/answers/75912/restrict-search-terms-conditionally-depending-on-the-index-being-searched.html ... View more

There is very little description on what extra_x509_validation provides in the URLs below, which appears to be a new capability. Is there a better explanation elsewhere? http://docs.splunk.com/Documentation/Splunk/6.4.2/Admin/authorizeconf#.5Bcapability::extra_x509_validation.5D http://docs.splunk.com/Documentation/Splunk/6.4.2/Security/Rolesandcapabilities [capability::extra_x509_validation] * Required to perform additional X509 validation through the /server/security/extra-x509-validation. ... View more