Receiving a '401 Unauthorized' error when querying the 'services/search/jobs' API

[cymulate]

Hi,

I'm working with .NET and using the 'services/search/jobs/' API.
After successfully connecting through the 'services/auth/logi'n API, I receive a SessionKey, which I add to the headers for subsequent requests as follows:

oRequest.Headers.Authorization = new AuthenticationHeaderValue("Splunk", connectionInfo.AccessToken);

When I received 401 error code after called 'services/search/jobs/' , I attempt to reconnect by calling 'services/auth/login' up to three times to retrieve a new session key and update the header accordingly.
Despite this, the session key sometimes remains unchanged (is this expected behavior?), and regardless of whether the token changes or not, I continue to receive the 401 Unauthorized error:

Response: '<?xml version="1.0" encoding="UTF-8"?>
<response>
<messages>
<msg type="WARN">call not properly authenticated</msg>
</messages>
</response>
'

Error from System.Net.Http: System.Net.Http.HttpRequestException: Response status code does not indicate success: 401 (Unauthorized).

The URL I'm using starts with https and the port is 8089.
Can you assist with this issue?

[yuanliu]

Is it possible that the token you use is created for a user that does not have permission to list other people's jobs?

[cymulate]

How can I verify this? How do I grant a specific user permission for all jobs? Does the user require particular capabilities or roles to search for a job? I noticed that someitmes the user has successfully accessed the "/services/search/jobs" endpoint , but encountered issues when using the "/services/search/jobs/{searchid}" endpoint.
Sometimes I got Unauthorizedon "/services/search/jobs" and sometimes got  Unauthorized on "/services/search/jobs/{searchid}"

[yuanliu]

You can go into token management to find out which this token belongs to, then go into permissions and find out what permissions the user has.

To think, every user who can launch a search should be allowed to use /services/search/jobs endpoint.  So, that is highly abnormal.  Maybe first test that user in UI to see if it can launch job manager menu.  Meanwhile, a trivial user should not be allowed to see another user's search, so denying /services/search/jobs/<searchid> can be the result of "otherness".

Also, it is not clear what exactly context defines "sometimes".  If the behavior is inconsistent over time using the same token on the same endpoint, maybe it's time to call support.