When posting setup.xml data to a custom endpoint, is it possible to make EAI calls that are properly authenticated and namespaced?

[sideview]

My problem seems very similar to http://answers.splunk.com/questions/4175/redirects-before-and-after-our-apps-setup-xml-with-a-custom...

but either its not the same thing or that thing wasnt fixed in 4.1.5 (because im using 4.1.5)

I have my setup.xml posting to my custom endpoint, and all is well.

But from that endpoint I dont have any user context. Specifically when I call splunk.auth.getCurrentUser(), i get back a placeholder user whose name is 'UNDEFINED_USER', whereas I'd expect to get back the user currently logged into SplunkWeb.

And obviously if i make namespaced EAI calls with that null user I cant do much with them cause he doesnt exist. 😃

and for troubleshooting purposes, if i throw the following line in there,

hackSessionKey = splunk.auth.getSessionKey("admin", "changeme")

then I do indeed get admin's user context and everything works fine, but of course that is not a solution.

So can anyone tell me how to get the proper user context from here? Thanks in advance.

[sideview · Accepted solution]

The solution was actually a headslapper. Custom rest endpoints extend MConfigHandler, and in that file there is a method getSessionKey(). I think the setup endpoints I had been studying did filesystem operations only so they had never called it.

Anyway, one might make the assumption that the python would inherit the authenticated session automatically but you have to actually call getSessionKey() or everything else will be dead in the water.

I had tried splunk.getDefault("sessionKey"), and I had read all through the other EAI python and through the API docs, but the answer was right there in MConfigHandler. Get a session key explicitly and suddenly ye shall be authenticated, and can make authenticated and properly-namespaced calls, and you can call

splunk.auth.getCurrentUser()

and all manner of sensible things.

This is the answer because without that all you can really do is simplistic writeConf calls:

self.writeConf(confFileName, stanzaName, keyDictionary)

But with a sessionKey you get a user context and you can can then use any endpoint in the EAI system, for example:

en.getEntities('data/inputs/monitor/_reload', sessionKey = self.getSessionKey())

which is very nice.

[Justin_Grant]

AFAIK, fixing the app context in the other issue linked above was easy because app context can be deduced from the URL. This makes the solution easy-- just make sure all app setups are sent (or redirected) to a URL for that app.

The user, however, is stored in a cherrypy session variable instead of the URL, so you're dependent on having it passed from Splunkweb down to splunkd and then passed again from splunkd to your EAI python handler. I assume that one of those handoffs is not happening, or isn't happening as you'd expect.

If I were trying to debug this, I'd suggest setting a breakpoint inside admin.init (the first method run in your EAI handler) and looking at all the info that splunkd is passing in as arguments and/or environment variables.

If the username is in there, then figure out a way to suck it out. 🙂

If the username isn't there, then I'd consider filing a support request on this since it sounds like something we may not currently support.

[sideview]

well nothing is passed in as arguments (just what you'd expect like ["\bin\runScript.py", "execute"]), and there's nothing useful in os.environ either. I forgot to mention that there is a promising looking constant "splunk.admin.CONTEXT_APP_AND_USER" that you can pass into splunk.admin.init(), but it seems to have no effect.