HTTP sessionid support over /api versus /jsonrpc calls

[dhaponnu]

I am trying to access NSO device data over its northbound apis via https://nsoserver:8080/api/xxx

I understand that NSO supports sessionid_8080 as a cookie over all /jsonrpc calls, but not over /api calls. The /api requests are authenticatied every time with username and password. In order to minimize the authentication for subsequent requests, I tried the following hack:

1. Make a /jsonrpc login with required username and password in the POST call

2. Fetch the sessionid_8080 cookie

3. Use it in the /api call (without using username and password)

4. I get proper response for the first call with the stolen cookie but the subsequent calls fail with "internal error"

5. I find the session ID set in the cookie is no more valid.

6. I am able to repeat steps 1-4 everytime on a new /jsonrpc login + /api pair

Is this a bug? Is there a way around?

I am intended to implement a API client that would make RESTCONF calls over the NSO /apis, but trying to avoid costly authentication for each request. I am not interested in having an external authentication mechanism to be able to leverage the token authorization that NSO supports by default.

Would be more interested to understand and know better as to why this hack doesn't work. Are the session IDs not valid for any http(s) calls from the same client, but over different endpoints like the /jsonrpc and the /api? Am kind of new to the http authentication world.

[Michael Maddern · Accepted solution]

Hi,

Using the JSON-RPC login is recommended and is not a hack (it's mentioned in the REST API user guide - at the bottom of the Introduction section).

I think the problem you are seeing is that REST doesn't allow granular transaction or session control. For each request, a new transaction is created automatically and once completed, the session ends. You need to authenticate each request so that a new session can be created. The REST / RESTCONF server uses an authentication cache, so it will be fast.

Alternatively, you can use the JSON-RPC API, where you have more control over the session and transactions, but it can require many individual API calls to do the same thing that can be done in one REST / RESTCONF call.

[dhaponnu]

Thank you for the clarification.

[perander]

Using the JSON-RPC login is recommended and is not a hack (it's mentioned in the REST API user guide - at the bottom of the Introduction section).

I think the problem you are seeing is that REST doesn't allow granular transaction or session control. For each request, a new transaction is created automatically and once completed, the session ends. You need to authenticate each request so that a new session can be created. The REST / RESTCONF server uses an authentication cache, so it will be fast.

It is not recommended to authenticate via JSON-RPC and use the session cookie for authentication with REST or RESTCONF. The mechanism has not worked for quite sometime, as described above. It seems that the documentation was not updated accordingly.