Feature: Login Status and User Authentication events

[panaaj]

Recent releases of the SignalK Node Server have introduced features that require a user to be authenticated before the feature can be used. Additionally some features are only available to admin users (e.g. applicationData/<appId>/<version>/global)

For client applications to provide a "trimmed" UI displaying the availability of these features it requires that the app be able to:

• Query whether or not a user is authenticated to the server
• Determine the type of user (or groups user is a member of)

Additionally an app needs to know whether there has been a change in the user authentication state e.g. login / logout.

Consider the following scenario:

• SignalK server starts (no user authenticated)
• Application is launched from WebApps section of the Server UI
• User logs in to server using Server UI.

When the application starts no user is authenticated and if it performs a "login status" check it will return "no login", so app will trim UI to reflect this situation.

When the user authenticates using the server UI the app is unaware of the status change until it specifically performs another "login status" check.

The proposal:

Add the following to the specification so each client connection can query and be notified of login status.

1. As SignalK node server already implements a /loginstatus endpoint, either formalise the current endpoint or define an appropriate endpoint and a response. The response should contain at a minimum the following:

   {
   userAuthenticated: boolean
   userName: string,
   userGroups: Array<string>
   }

   • userAuthenticated: true / false indicating a user is authenticated on the server
   • userName: name of the user authenticated on the server
   • userGroups: and array containing the names of the groups the authenticated user is a member of.

2. Define an authentication notification that is triggered when a user logs in/out of the server that apps can subscribe to and respond to the changing authentication status. e.g.

   {
   path: notifications.authentication,
   value: {
     userAuthenticated: boolean
     userName: string,
     userGroups: Array<string>
   }
   }

[tkurki]

I agree, this should be added to the specification. We should push the related http paths also under /signalk.

Not sure if notifications is the way to go - if we decide to use that then it should be compatible with the generic notifications, with additional payload fields to provide machine readable data.

[panaaj]

I really meant a delta type message rather than a notification...but clearly didn't type it that way. If delta type message is the way forward would the context still be self (as this generally refers to the vessel) or would it be something like server which could then be used for other "implemented" features and possibly aid with "feature discovery"?