Make clients workspace aware when run on remote system

ni / nisystemlink-clients-python

Python API for interacting with a SystemLink Server, created and supported by NI.

https://ni.com/systemlink

MIT License

10 stars 14 forks source link

Make clients workspace aware when run on remote system #63

Closed santhoshramaraj closed 4 months ago

santhoshramaraj commented 4 months ago

On a remote system, using the SystemLink client to create data without explicitly passing the workspace_id results in data created under default workspace and often experience not authorized error if the remote system is not part of the default workspace.

The LabVIEW SystemLink client API uses the workspace_id from the SystemLink Client, whereas the Python equivalent doesn't.

The remote system is aware of the workspace it belongs to through the SystemLink Client application's HTTP configuration.

It would be nice to have the clients use the workspace_id of SystemLink Client (if available) as default instead of the default workspace.

spanglerco commented 4 months ago

@santhoshramaraj, API keys can carry a default workspace that is different from the "global" default workspace. When a system becomes managed by a SystemLink Server, the API key that gets created for that system has its default workspace set to the workspace that the system is in. So any requests made using the system's API key that don't specify a workspace should already go to the system's workspace without any client API modifications. As far as I know, the LV client API doesn't do anything special in this regard: it simply uses the system's API key without specifying a workspace.

Are you seeing different behavior where a system's API key doesn't have the correct default workspace assigned to it? Or is it specific to a service that you're trying to call?

santhoshramaraj commented 4 months ago

@spanglerco Your explanation holds good with the nisystemlink-clients-python when used with SystemLink Client application on a remote system - verified using the DataFrame example.

I raised this request based on a past debug with the customer on SLS connectivity.

The following snippet in the LV APIs made me think the workspace.id was read from the salt-grains whereas it was "" at runtime on the remote system.

Does this concept of API key's default workspace apply to all services and queries when workspace is empty?

spanglerco commented 4 months ago

@santhoshramaraj Yes, it should apply to all services because it's the auth service that implements it. The auth service is what every service calls to translate API keys into actions that users are allowed to do and in which workspaces. If you see any services where this isn't working, that should be considered a bug in the service.