Same app. As I said, I was following the link from the alert email. The upvotes on this must be from folks with a different issue. ... View more

Thanks, that clear things up greatly. Seems like the approach we're taking (toggle via a documented environment variable) is as good as any. ... View more

I think you're answering a different question than I'm asking. I think I may have erred in using the term "validate" rather than "verify," as what I'm referring to is the certificate verification that takes place in automated fashion as part of SSL negotiation. SSL tools and libraries (such as curl, and Python's "requests" library) enable verification by default but provide a flag to disable it if necessary. My problem is not with how to do that verification (what your answer seems to be about, though I still find it odd since the cert is provided by the server as part of SSL negotiation) -- I know how to do that, as it happens by default with these tools and libraries. Rather, my problem is that I need to recognize situations in which verification should be disabled. Such situations would occur any time there's a legitimate need to make REST calls to a Splunk installation that doesn't have a valid SSL cert configured. I'm thinking of two categories: Local testing during add-on development. Installation of my add-on by an end user who, for whatever reason, has not chosen to set up their Splunk installation on a host with a valid SSL cert. I can work around #1 through temporary hackery, but I'm concerned about #2. If I don't provide some way to support such users, they'll be unable to use my add-on. It appears that many existing apps/add-ons address this issue by simply disabling SSL cert verification in all cases, but as I mentioned this seems like a poor security compromise to undertake. What I'd consider ideal would be if, when invoking the add-on, Splunk provided some indication that the Splunk app server does not have a valid cert available, so verification should not be attempted. I'm guessing no such means exists, and it seems unfortunate because I believe this problem would apply to any app/add-on that needs to make REST calls back to the Splunk server. Surely this is a common use case. After discussing it within my team, the best workaround we've got is to add a toggle based on an environment variable. That means that, if an end user wants to use our add-on but doesn't have a valid cert set up, they'd have to set up that environment variable when starting up Splunk. It's workable, but kind of an ugly thing to have to ask users to do. I'd love to hear any ideas to improve upon this approach. ... View more

That did the trick as far as making the config value appear (discovered this yesterday, but thanks for confirming), and values I enter still round-trip properly. Unfortunately, I'm still not able to get the behavior I want in terms of providing a default value. I can see why the data binding does what it does, to populate the previously-configured value; and that's why having the param name be the same works -- but it feels like a hack to name my default value config key the same as what it's a default for. The problem with this hack comes to the surface when I configure a new default, because that default then propagates to all existing alerts. I think it would work how I want if it would actually respect the value attribute in the case when the param is absent, but that's not how it works. Anyway, thanks. ... View more

I've spent a good part of today reviewing those docs and trying to get something to work here, but with little traction. Are you sure this is possible for a custom alert action UI, as opposed to a dashboard or something? For custom alert actions, we only provide an HTML snippet rather than a full document. When I add <script> tags outside the existing <form> tag, the UI breaks (nothing shows up). I looked through all the add-ons and apps I could find that provide custom alert actions, and didn't find any examples of this. Am I failing to understand, or is what you describe not possible in this context? ... View more

Marvelous. 🙂 ... View more

My default value does (also) occur in alert_actions.conf, but I don't see it getting populated in the UI based on that. What would you say needs to be in my HTML for that to occur? ... View more

Awesome, much appreciated. ... View more

Odd, I thought I already responded to this. Oh well, here it is again. Yes, using "placeholder" is what I've had to fall back on as a workaround, but it's not really the same thing as filling in the actual value. The UX is inferior with a placeholder, because: The user has to type the text in by hand. As soon as the user starts typing, the placeholder text isn't even visible for reference. They can't copy/paste it either. There seems to be at least one other significant problem (bug, I would say) closely related to this behavior (see answer #386595), so I really think it deserves a look. I've perused the links you provided (having mostly already done so), but find nothing helpful. I don't imagine there's anything about my expectation here that's out of line with Bootstrap's needs, is there? ... View more

(XML didn't show up right when pasted into the above comment) ... View more

I think there must be something else I'm missing. The REST API doc examples for this endpoint actually show the URIs hit by the SDK: curl -k -u admin:changeme https://localhost:8089/services/storage/passwords But the sample XML response shows the "serviceNS" endpoints that I've been (successfully) hitting via direct REST: https://localhost:8089/servicesNS/nobody/search/storage/passwords/%3Atestuser%3A (etc) What exactly is the deal here? ... View more