how can client determine if it has read, read/write or admin access?

[seandepagnier]

I cannot tell from the client which type of access is granted from the requests to the signalk server, only APPROVED is given rather than specifying the type of access.

I realize read access is available without a token, but I wish for the user to grant read access to pypilot so that if the connection is not wanted it can be prevented in this way.

It seems to work with read-only, but data is written to signalk and ignored which is a waste as the program does not know it will be ignored.

[cmotelet]

fetch /loginStatus

{
"status": "loggedIn",
"readOnlyAccess": true,
"authenticationRequired": true,
"allowNewUserRegistration": true,
"allowDeviceAccessRequests": true,
"userLevel": "admin",
"username": "myUsername",
"securityWasEnabled": false
}

[seandepagnier]

Thanks for pointing me to this, I had thought it was not implemented.

[tkurki]

I am reopening this as this is not quite the whole story. There is also per path access control, so a client can have different read/write access for different paths.

How about an api that would allow you to query access for one or multiple paths? This would work nicely over ws, where you could send a query message listing the interesting paths and receive a response listing the accesses - all within the connection where the access is valid (unless the admin changes ACLs on the fly).

HTTP has rthe elated OPTIONS method that could be used, expect that Signal K's unfortunate unconventional use of POST/PUT doesn't work well with that.

[seandepagnier]

Thank you! So with different access for different paths, how does the user normally grant access to specific paths?

I prefer websockets. I am using only the http to gain the access token. Are the ACL combined with the login access by the server? Or do I need to check both the access control list (ACL) as well as the loginStatus?

[godind]

Thanks for pointing me to this, I had thought it was not implemented.

In my opinion the login response should include roles/permissions, ACLs and the JWT token. This would streamline the process.

Having assigned permissions at hand allows clients to control available app features easily. E.g. can the user r/w to applicationData global key, can he send PUT to value commands, can he update meta or plugin config, etc.