All Apps and Add-ons

Add Credential error

cuke
Engager

Get the following error when Add new credentials for PAN devices:
Encountered the following error while trying to update: In handler 'localapps': Error while posting to url=/servicesNS/nobody/SplunkforPaloAltoNetworks/admin/passwords/

I am using admin to edit it and admin is the owner of the app. I manually edited the setup.xml and app.conf, adding the credentials. But when I open configuration page, credentials are still empty. Can't add the credentials from app GUI.

Do anyone know about the problem? Thanks.

jpass
Contributor

Adding some information in case others might find it helpful. For me this is what happens:

In Splunk 7.2.4 for custom Splunk App:
- there is no way from Splunk Web to update the password for a username already stored in passwords.conf without deleting passwords.conf
- adding credentials in splunk web when you first setup the app works with no error and passwords.conf is created and creds are stored as expected
- if you add credentials with a different username it throws the error but a new entry is added to the passwords.conf file
- if you try to add creds w/ username that already exists in passwords.conf, it throws an error and no changes are made to passwords.conf

It's not a big deal but my goal was to avoid having users to ever have to edit conf files. I wonder if I can write something into the app using python sdk to do the work. We'll see.

0 Karma

38sdfjh8347
New Member

Hi @jpass  - just wondering if you ever came up with something to handle this type of issue?

 

I was wondering the exact same thing (i.e., can something be done to avoid having users delete conf files, etc.)

thx...

0 Karma

jpass
Contributor

It's been a while. If memory serves me well...I ended up creating a modular input using the Splunk Python SDK.

https://dev.splunk.com/enterprise/docs/python/sdk-python/howtousesplunkpython/howtoworkwithusersrole...

0 Karma

salbro
Path Finder

I had a similar issue with another app that stored an authorization key. Removing the file and restarting worked for my case. Thanks!

0 Karma

bercules
Engager

Usually that error means the wildfire api key is already set.
strong text
Starting in Splunk 6.3.0 the credentials and api key are now stored in local/passwords.conf instead of local/app.conf. Try deleting the passwords.conf file (or remove the wildfire api key from it), then restart Splunk. That should clear it out so you can try to add the API key again in the app configuration screen.

For example:

rm $SPLUNK_HOME/etc/apps/SplunkforPaloAltoNetworks/local/passwords.conf
$SPLUNK_HOME/bin/splunk restart

darlas
Communicator

I wish I had same luck as BrendanCO 😞 I deleted both app.conf and passwords.conf in ./local then restarted splunk. I still get the error. Oddly, the passwords.conf file gets created but only stores the user/password, NOT the Wildfire API key.

So I'm halfway there.

Any thoughts?

0 Karma

BrendanCO
Path Finder

This worked for me. Thanks!

0 Karma

duartet
Path Finder

Me too! Thanks!

0 Karma

reswob4
Builder

If you problem has been fixed, please mark this as resolved so others know.

Thanks.

0 Karma

darlas
Communicator

I had the same issue upgrading to PAN App 4.2.1. By deleting local/app.conf then restarting splunk I was able to get passed this.

Thanks tdepuy!

tdepuy
Path Finder

I am getting the same errors while building my app. I found that nuking the local/app.conf file then restarting splunk resolved the errors, but they would pop up again if I ever wanted to update the credentials.

btorresgil
Builder

Hi cuke, the credentials in the setup screen will always be empty, even when a user and password have been entered previously, that's just how setup.xml works. The user and password are stored in SplunkforPaloAltoNetworks/local/app.conf. You might try starting over by removing any credentials found in that file, and entering the credentials again in the browser on the setup screen. There isn't any feedback if it works correctly, you'll just find that local/app.conf now has encrypted credentials, which means it worked.

That lack of feedback from setup.xml isn't ideal, but we handle it this way so that the credentials are stored encrypted. I believe in this case security is more important than convenience.

0 Karma