Session Management
Login and Admin UI Remember Me
This is a follow up about https://github.com/SignalK/signalk-server/pull/1670 and the login infinite look it creates in KIP
I assumed the Admin UI worked like most sites: check the box and it log's you in automatically. You still need to get a token and it expires but it will renew automatically in the background for you. In any case, thats not really the issue since it's a login feature of the Admin UI, right?
I think the "Remember Me timeout" should only affect the Admin UI and not the login API response token TTL. In my view they are two separate things.
Because they are tied and v2.6 changes "Remember Me timeout=NEVER" as the default (see thread from Jess on this) it has more impact and will create support questions, at least for Kip.
NEVER was not listed and an option before in the "Remember me" (still not in v2.6). It only used to apply to Device Tokens. At least from a UI perspective (see image).
In short, I think the Admin UI "Remember Me timeout" and how the login API generates User Session token expiration should be two separate settings. Else the Admin IU's "Remember Me timeout" settings also affect all other apps using the login API, be it from a local or a remote call. Makes sense?
34 Replies
The security setting for rememberme timeout is for the server, not the admin ui. Admin ui has plenty of settings that configure the server: that is kinda what the admin ui’s primray purpose is
What is the actual problem here? The infinite loop? What exactly is the mechanism there that is is triggered by the NEVER value? Can you point me to Kip code that handles login & tokens?
Are you angry?
Forget about the code for a moment. I'd say if we both don't understand this simple subject, something is not clear about what things do and/or how it is presented in the UI.
- First, in the login screen have a "Remember Me" toggle option.
Based on most common application, this makes apps and sites remember your credentials automatically. Just as it says. Maybe it even log you in automatically. Is that what this toggle does?
- Second, in the Admin UI's Security / Settings, the is a "Remember Me timeout" parameter which appears to be very closely related.
If the "Remember Me timeout" parameter sets tokens expiration rule for user logins, including login api calls, it should be named accordingly. If it's not what it should do and that it should only apply to the local cookie token, there is a bug because KIP does not rely on cookies and it receives NEVER in the token result from the login api response.
- Thirdly, I don't understand why we would put to NEVER by default, unless it's not important to have that level of security by default. In this day and age, I'd say it's advisable, the feature already exists and works very well.
If KIP needs to handle the new NEVER token expiration , I'm sure you would do a better job then me, but I'll first try to fix it. This option was not listed as a possibility in the UI before. If the new option stays, the UI should probably be updated because once you change NEVER to something else, there is no way to know, if you don't remember later, that it's a possibility.
Hope this helps
sorry if my burst of short questions sounded angry, was just a bit busy so they came out that way
i'll try to write a bit longer description of how the server works and how i (and i think Scott to some extent) have envisioned things to work over the weekend
1) when you call login endpoint with RememberMe the server response sets a cookie that is set to never expire and the jwt in it never expires. when you restart the browser the cookie remains - it is the same session, so technically it does not log you in automatically because you were never logged out, browser restart has no effect
without RememberMe set in login the cookie has no MaxAge set and the browser deletes the cookie on restart
Admin UI relies 100% on the cookie, just calls server with
credentials : include, nothing in http headers
2) currently there is only one setting for session timeout. it affects both the jwt and cookie lifetime. can be renamed in the UI. can't be simply limited only to cookie, as then there would be no way to control the lifetime of token's lifetime
3) the idea for changing it to NEVER was brought up in Slack: people complaining that they are constantly logged out. As i phrased it in the PR: "as a user when I login and set RememberMe to true I expect the server to keep remembering me, over browser restart, with no set time limit"
You argued that "NEVER" was not there before so it should not be added. I don't buy that argument - if we continue in that direction we can never change anything, because "it was not like that before". Certainly we want to minimise hassle and problems, but be able to progress
to me a core problem here is that I did not understand that Kip manages tokens independently and that this could cause trouble. NEVER was already in use for device accesses, so I assumed this change would not cause issues
i asked about pointers to Kip code to just better understand how things work there. code is the ultimate documentation, albeit nontrivial to understand 😁PS. concise Discord thread names help navigating Discord, the beginning of a post is rarely useful as the name
No problem. It’s water under the bridge…
I fully agree things need to evolve 👍
To further my knowledge: I want to understand if the Serve (not sure how to name it - I mean the SK service) handles Users and Devices session tokens separately from the Admin UI:
I assumed, probably wrongly - but it made good sense, that the Server handled both User and Device tokens independently from the Admin UI. That for the Server, both token types (Users and Devices) worked the same way with one exception: User tokens don’t required manual approval in the admin UI. So for this this meant the server has a "token store" for each Device and/or User with the expiration logic.
Again following my assumption, the Server automatically generates, saved to the “token store” and sends back the token in the response upon login api calls (or device token api, don't remember if they are the same...).
When the server receives a request with an expired token, it refuses to process and return a 4xx error (I don’t remember the exact error number). It’s up to the app/client to handle the exception.
So, again with my assumption, the admin UI used a User token but saves it in a cookie for it's own use.
Unknown User•9mo ago
Message Not Public
Sign In & Join Server To View
So onto how KIP works: keeping in mind it's mostly ran on different devices than the server, KIP always make a login api call on startup and injects the token to all subsequent API requests. It decodes the expiration date from the token string, and auto renews seconds before it expires - it simply make a new login api call.
Tokens are never saved and no cookie is used
Thanks Jess. I think KIP needs to handle NEVER for User tokens. It does for Devices tokens already. I just need to find time to fixed it and release, but I have a big PR to commit first. I'll see what I can do to expedite.
@Teppo Kurki unless we think a NEVER expire User token is not a good thing
In my interpretation of how things worked, for me, the cookie, and it's contained token, was only related to the Admin UI, meaning both the "Remember me" toggle only update the Admin UK cookie and that it had nothing to do with how the Server handled tokens and their expirations.
It's probably not how it works, but it would make real good sense.
It would fix one issue: when KIP makes the login API call, it would not force a cookie token update and unexceptionally change the user and permissions used by the Admin UI, or other apps that use that same cookie.
The User session token NEVER expire issue is something else. KIP needs a fix if NEVER is a possible value and somewhat fast because it's now the default.
@Teppo Kurki I'm here to have fun and so are you. I’ll try and take things less personal 😉
here's (somewhat opinionated) documentation on how sessions work https://github.com/SignalK/signalk-server/pull/1692
i think a core question here is the direction where we want to go:
1. all webapps share the same session
2. each webapp manages its own session
what i don't quite see is the value for users in going for (2) - in what real world use cases has that more value than shared sessions?
a practical use case is opening Kip and Freeboard in two browsers windows or Kip embedded in Freeboard: with shared cookie based sessions everything just works, no extra effort needed (please ignore the fact that Kip-in-Freeboard is already implemented, let's imagine i created KipsrtumentPanelSteelSeries the next gen instrument display thingamagic)
i assume that by far the majority of servers out there with security on have only a single user configured
to me "single sign on" is by far more valuable than the case where you want different identities in different windows in a single browser
I have not yet looked at the link yet. Need to sleep! People use apps remotely and have different people on board. Think of racing crews and large working ships, or just husband and wife. They want/need different configurations from the same app to suit their needs. I had a question just today in the Kip channel on this. I’ve had others ask before as well simply because their guess/wife constantly messed around with their config from their personal iPad but with the same user. I use this feature myself. We have applicationData user key for that purpose and it works great. It’s a real active use case. It’s simply that this small part of SK is still designed with a one man, one nav station simple approach that it probably started with. It’s a simple improvement to finalize this evolution.
Sorry i distracted you, of course multiple users are definitely needed
But what concrete use cases are better served by session-per-webapp instead of shared sessions? When would one need different identities in different webapps in a single browser?
This is not about applicationData per user, that works with either
I can think of one mechanism we are missing for shared sessions: webapps getting notified of ”current user” changing. But that doesn’t work with session-per-webapp either if you have multiple browser windows with Kip and you login as a new user in one of them, the others won’t notice (i assume, have not tested)
Right. They don't affect each other.
Been reading and it's a very good addition. I'd like to make suggestions, even contribute, if I may. I'm a not knowledgeable about SK code just as most non-core team devs are. May be my insight could help address this reader perspective. Let me know if/how you want the collaboration to happen...
Here is how my newbie brain approach the subject:
1. Server Tokens: state management, expiration, User vs Device tokens
2. Authentication API: Login, Logout, Validate, HTTP vs WebSocket
3. Device Access Requests: Requests and Admin UI approval
4. Cookies: Concept and application
5. WebApps & Plugins implementation: What you would use and what's their benefits/limitations/impacts
Not sure Admin UI is relevant in this context. It's just another WebApp... I'd make a page dedicated to Admin UI and explain the Remember Me login page toggle.
Just a quick draft but it's what I had to figure out in steps.
@Teppo Kurki few more questions on the subject:
1. What happens with the token validity when you call logout api?
2. Does it affect the cookie token content if so how?
3. Does it impact remote clients token validity?
the base mechanisms are documented at https://signalk.org/specification/1.7.0/doc/security.html but that is not very practical
yeah. I read it before implemeting login in KIP, spoke with Scott, re read it today and still not clear on some things
all logout does is remove the session cookie. it has no effect on the token
what do you mean with "remote client"? what is a "non remote client"?
too bad i missed that conversation. well, better late than never
sure, we can document these together. i am so far in that i can't see what others don't get. but the thing is there are multiple ways for doing things and some of the stuff is just built in browser logic, like including cookies and no access to headers for ws connections, so i am not too eager to replicate all that
makes sense
so that means:
1. the token is not related to a user, it's just a key with expiration, right?
2. api requests to ApplicationData 'users/<username>' is available to any logged in user, right?
Want me to contribute to the PR? I'll use the structure I proposed and leave points open to you when I don't have the answers. Then see if you like it.
1. no, the token does contain the user's identity
2. no. your path is not correct, it is singular
/signalk/v1/applicationData/user/ and username is not part of the path, the user's identity is from the authenticated userI mean the the folder path ~/.signalk/applicationData/users/<username>
what about it?
call to /signalk/v1/applicationData/user/ automatically maps to the ~/.signalk/applicationData/users/<username> folder, right?
yes. so what is your question?
just trying to make sure I understand so if/when I change KIP, the everything still works.
as a webapp author why would you care about directories on the server, as you work with the server's API?
is it a problem if I do?
or were you asking "is user specific applicationData available for all users"?
So to support cookie in KIP, the limitation would be that you have to build you KIP config with the same user as the users you want to use in other apps. That would be ok.
well, you talked about api requests but used concepts that are not in the api but directories on the server, so just trying to understand what it is you are asking / verrfying. no problem at all
Sorry. I was validating the relationship between logged in users and config storage folders so I can implement that change properly and explain it to users
the authentication method, cookie or header, does not change the user that you are authenticated as and under whose application user data Kip settings are stored
switching to cookie based authentication should have no practical effect to the end users' settings
except in cases where people login sequentially with different apps in different windows
or there is something i am not getting?
you login as user x, your settings are saved under user x's applicationdata and can be retrieved later
I get it.
More questions! How does the server know who's who and what rights they have, if you have many people on different devices with different users?
they login with their username, then the username is included in the cookie/token payload
when handling a request the username is extracted from the cookie/token and used to look up their access level details
So the token contains the user? Or it’s in some other cookie key?
yes, it does. above i already answered the token does contain the users’s identity and the username is included in the cookie/token payload - is there something still unclear about it? (no offense, just thought i made this point 2 times,)
This was the statement that confused me
Not sure where this is heading, but the question was asked if we need per-app sessions/auth or a shared session/auth. In my boat's setup, I have a display connected to the machine running SK at the chart table. There I want to use the SK UI as admin to do all the important SK stuff. And (in the same browser) I also want to use KIP, but as a user with only r/w permissions and probably sometimes changing user to get different instrument setups. All without interfering with the "remember-me-login" as admin in SK UI running in another tab.
Would that mean per-app sessions?