Session Management – Servoy Tech Webinar No.58

We are at number 58 in our long running series, doing these almost every two weeks. We had to cancel last week because of some scheduling and projects and that sort of thing. But we’re back on track and today number 58 is all about session management. The reason I selected this topic is because, well, we typically do these webinars to announce new things, show you new features, new capabilities, but also we try to fit in some how-to stuff. And the how-to stuff is typically inspired from real-world customers, real-world projects. And hearing on phone calls and meetings, gee, how do we do this? We’d like to do that. If I hear something more than once, then I know it’s probably webinar worthy. And I’ve been hearing questions related to sort of managing servois, stateful sessions a lot recently. So of course, we start every one of these tech webinars with demos so that if you decide it’s not for you, you can bail before you get to all the boring slides. Today I have kind of three or four demos here. And we’re going to talk about, excuse me, managing sessions in terms of when the session should be timed out from the server side. Also handling what happens if the user themselves are kind of idle in the client. There will look at ways to programmatically access what’s happening in all of your sort of connected sessions. And we’ll take a real-world look at some custom session rules and how to use that programmatic access. I think it’s worth noting before we dive in here that servois is different from a lot of other platforms and that we provide a stateful client session for every connected user. And with that comes a lot of great power, but then also some of the questions that arise with, well, what do you do if a user closes their tab and then reopens it or navigates away and hits the back button. What happens to the session? These types of things. So that’s what I’d like to dive into. For the first example, what I’d like to do is bring up a little solution that I made this morning. And it is called Example Session Management. And what I’ve done is I’ve made a little login here. I’m going to log in as myself. And away we go. Okay, a little form here. Now what I’d like to focus on is not the application itself, but what’s going on in the sort of on the back end. And for that, I’ve brought up the servois admin page. And for those of you new to servois, this is a very commonly used part of the platform. This is where you can go and have a look at the overall application server. So lots of stuff here that you could get into. But for this particular demo, we want to look at this session over here and what’s going on there. So you can see that it’s tracking sort of when it was first connected. How long it’s been idle and that’s sort of idle on the server and I’ll explain what that means. And also if you look, excuse me, at the client ping times, you can see that the server is sort of keeping track of that client because a web server doesn’t really know what the status of what’s happening in a browser unless it communicates with it. So in this case, it’s you can see that the web socket ping as I reload, you can see it’s responding. Now, if I come back here, we’ll get to this in a second I that’s my next demo. I’m going to log back in it’s still the same session. I’m going to come into here and let’s say that I’m using this and I hit the browser tab or I hit the browser X out tab. Now, if I restore that tab control shift T and my browser, it comes right back to what I was doing. So I moved in that’s dayful session is preserved because it hasn’t been cleaned up on the server, you can see that the connected time is the same and that ping time just keeps going up. So the servers keeping track of the browser, even though I closed it, I could still go back I could navigate away and hit the back button and the result would be the same. So let’s say that I close it and then I don’t come back after a certain time. Well, then what happens is eventually this is going to get cleaned up. And so I want to show you the setting that manages that because I see a lot of questions on our forum, I deal with a lot of questions in customer projects. So you go to the application server homepage and you scroll down to an ng client setting here called, Sablow window timeout in seconds. So I have set this to 10 seconds, which is pretty short, which means that after about 10 seconds of idle time, meaning not idle the user’s not doing anything, meaning really the client is disconnected, the browser’s not responding to WebSocket request after about 10 seconds, we want to go ahead and and clean up this session to get rid of it. So if I go back to my clients here, now you can see that it’s already timed out that that browser that I xed out has been cleaned up. So that stateful session is now gone. I’m going to hit the control shift T to try to bring it back. So I see that I have to relog in again that my stateful session is not there available for me. So you have control over again over this setting. I’ll go back to it is this under ng client, Sablow window timeout in seconds. So you have control over that and the one of the real world cases we see is that the default of 60 seconds. So if you don’t touch this and you just start your server application your session will be reclaimed after 60 seconds. And in general, you want that to be a low number. You want it to be pretty quick because if a user has left, then they’re probably not coming back or if they do come back you want them to just reload relog in one of the examples that that I ran into as a customer we’re working with who. does a lot of like greenhouse management systems agricultural and logistics and they have a mobile app that is for tracking deliveries. So the driver actually has this mobile application and maybe they’re driving for three hours and and they become disconnected because of you know, spotty, you know, cell tower reception, etc. And in that situation, we actually want to keep the client alive so that the next time they picked up the application it’s right where they left off. So in that case, we set that to a very high number maybe several hours. So that’s one real world example where you may want to change this and usually if you want to change this is because you want it to be longer you want to you’re expecting internet disruptions. So that’s kind of my first demo it’s more of a look at sort of how things work and how we’re identifying how these sessions are handled on the server and typically it’s these these dates you see here when it was first connected how long it’s been idle when was the last ping from the web socket. The second example I want to show is measuring idle time in the client, which you got a sneak peek of that minute ago so i’m going to go ahead and and log in here. And well, while i’m working here i may be clicking I may be you know typing things in the keyboard all of that time i’m able to track well the user’s busy now if I if I were to close the the window or navigate away. Or just stop using my mouse I might start wanting to count and say hey after about a minute or so of that we want to. Ask the user if they’re still if they’re still working so while while i’m leaving that up i’m going to go ahead and let that go idle and sort of go under the hood and show you how i’ve set that up. So in my application here example session management I have created this. This on open handler and so this method here is called when the when the application first loads. And i’m saying that after 90 seconds I want to. I want the application to time out. So i’m using this public or sorry this plug in sfi idol and it has one method on idle now this is something that’s available through the web package manager so if you if you go to web packages and download install with web package manager. And go to ng services. Take some minute to load here you’ll see it there called idle web service so if you just click the plus button it’ll install it. And then down here under plugins you will see it it’s called. Sfi idol there is at the very bottom has one method on idle and basically what you’re doing is you’re telling it. What you want to have happen when it realize you realize that the the user is is gone idle. And so the first argument is your your call back so if I go to that function it’s right here below. And basically what i’m doing is i’m. I print a little message out to the console but what you saw on the client was i’m showing this dialogue saying your session has been logged out due to an activity and then I call. Security dot log out so they’re actually kicked out of the application. The reason that we created this plug in is we were working with a software vendor that. That creates financial applications so applications for banks and they were making a consumer mobile banking app. And typically when you work with sensitive data like financial data you don’t want to leave applications sitting around idle so if you walk away from your application. Or you set your phone down that then someone could pick it up a few minutes later and and just. You know already logged in and make a bank transfer or something so they wanted a pretty short. I don’t time out in this case we’re measuring idleness in terms of the users what they’re doing if they’re. You know using the application down in the client. So it’s pretty simple. You pass in the on item on idle call back there’s a couple other things there like it’s actually showing. When the user is gone idle when they come back then it goes back to this on active and I can actually launch this in the engine client right here from developer. And show this to you. Just give it a second to launch. Meanwhile you can see back here my first session says you’ve been logged out due to in activity and then when I click close it boots you out of the system. So. Why don’t we take this down to something really small like 10 seconds. Or 10,000 milliseconds. And then log in. And I’m going to bring up the console over here and you can see it says application started with idle time out. And now it says user idle you can see that it printed it out so I’ve already hit that method and then this pops up. So what you can do is if you minimize it you can see that. It calls application hidden. And when I restore that guy. You can see it says application shown. It’s also saying that the user became active again. But at this point because of security concerns I want to say the first time they go idle I’m in a log them out but it’ll actually keep calling that idle. So it’s not necessarily that you always have to log them out you can do what you want here. It’s up to you. So this is a nice little plug in that my colleague made and it’s available through the web package manager and this is how you use it. Again the use case is typically that you want to log someone out if they’ve gone idle or you want to ask them if they’re still using it. That sort of thing. The third demo that we’re going to do here is to show program programmatic access to the stateful sessions. So this is more like you have a manager application or you want to enforce some custom rules. So what I will do is. We can go ahead and close that one. I’m going to fire up a couple of these clients just in different tabs. And I’m going to go ahead and log into them with different users. I’ll put me on in there too. Okay. Now I’m going to go to this one in my sessions list and you can see that I’ve actually created a form that’s showing me the connected sessions. So you can see that I have the user that was logged in. The IP address in this case everything is local host so that’s not very exciting. And you can see that there’s like the host name of the computer, the solution that was loaded and then some of these. These times here and if I were to refresh this then I would I would see those update the same as as you see on the application server. However, the reason that I’m showing you this is I was once working with the customer who wanted to have sort of a super user. be able to log in and see who else was logged in and you know kick them off or that sort of thing. And this is the way that you can do that. The other thing you can do is you can you can programmatically shut down. The clients by clicking one of these or you can you can send them a message. So let’s say that I want to go to the first one that was logged in. And send a message. Hello world. And you can see there’s a little notification over here in my browser. This one has already been logged out due to an activity but it’s still it’s still an active session. And you can see the message there. I can come back here and then shut them down. Are you sure you want to. Yes. And now although the modal dialogue is still there. This is the pages actually expired. If I if I can figure to you know a log out page that would it would be redirected. But I get the default here. So there you can see that from one client I programmatically booted enough client. I also sent them a message. So you could you could do things like that. There’s actually a lot more you could do because there’s a whole broadcasting API. But that was covered in a in a prior webinar. So we won’t get into that. I just want to show you that you can do this. And if we look under the hood. And we go to the form that is showing it’s called sessions. And you can see that I just made a grid here and I put some some fields on here. But the data source that this form is based off of I made it in memory data source. And I’m loading it. I’m loading it by using the client manager plug in. So I’ll show you the code here called. Load client sessions. And this gets called when the form first loads and tries to initialize that found set. And the important part here is. We do have webinars all about how to use in memory in memory tables. So I would ignore this part and go check out that webinar. But it’s really this part here this plugins dot client manager. It gets a list of these connected clients. And here what I’m doing is I’m just creating rows in a temporary table with all of the information there. And that automatic because that’s a data bound form. It just happens automatically. It shows up in that grid. And then there was a couple actions there. In sessions, if you look behind these buttons. When I went to shut it down. Plugins client manager shut down and I just grabbed that client ID or send message. And again, I just grabbed that client ID. So. And so basically you could you could manage a list of clients. Some things I didn’t show that I wish I had more time to show would be. You can also attach custom. Session information to each client. So if you wanted to know which clients are doing this or that. They can sort of. Post their own, you know, inject their own variables or session. Information and you can find clients based on that. And you can look at their custom info. So if you’re doing that, you could, you could do this at a much more nuanced level. And again, there’s also a whole broadcasting API for sending like information packets back and forth. Between clients on different channels and there’s a whole other webinar on that. But this is just to let you know that you can programmatically see and manage sessions. And I want to show you a real world use case. Why you might want to do that. And I was working with a customer who wanted to be able to enforce the rule that. That a user could only log in once at a time by default. Servoy doesn’t limit you based on user or 10 or anything. You can log in as many sessions as you want with the same. With the same credentials or what have you. So now what I’ve done is created a rule that says you can’t log in to the same session. Under the same username more than once. So I’m going to log into this one. And I have my my idle time out set pretty low. So I have to do it quickly. So I’m going to log in as as Sean. And I’m going to log in over here. Under the same username. And now you can see I get this message that the login is failed because I’ve already logged into another session. And my custom rule is that only one session is permitted per user. So I could just cancel and be stuck here on the login screen. Or I could say, Hey, I’m not using that other session. I left it on my computer at home. Here it is over here. I want to close that other session. And you can see this one gets the boot. It’s already gets that error page or the expired page. Of course, that could be custom. You could also show a dialogue that says you’ve been logged out or what have you. And over here now I’m logged in. So that’s an example where I want to have some custom sort of session management built into the application. And I use that client manager plug in to do that. And we can take a look real quick at how that was done. If we jump into the on login method. You can see that at the beginning what I do is I check for another user session. And so I’m going to get a sub method down here. Get user session. And what it does is it gets that list of connected clients again from the client manager plug in. And it loops over those clients. And if the username matches the username that we’re trying to log in as it returns it back. And so I’m saying if there is another session. And so I’m going to sort of hold on to that because I might want to close it. And then I’m here I’m asking the user what they want to do. And if they do decide to close it, then I call that shut down client. So the same example I showed you before, however this one has a more real world use case. And then after all that’s done I proceed with the login as normal and just log that user in. So that’s the that’s the real world use case for one of the use cases for programmatic session management. And sort of do a quick overview and then we’ll get some questions. So let’s go back into presentation mode here. So the first demo we looked at was what I call server side timeout setting. And this is really determining how long you want to keep alive clients which are really disconnected, meaning the server can no longer see. And I’m doing air quotes here no longer see the client because of some disruption to the WebSocket connection. So they’ve stopped responding and what do you want to do. Do you want to leave them open for a really long time. Do you want to close them quickly. It’s up to you. You use this this setting that you can find on the administration page. And again the real world use case for that is when you do expect a loss of network, then you would maybe want to bump that up to a high a high level so you can give users the freedom to reconnect automatically and keep their session even if they’ve been had a network disruption. So common maybe for mobile applications or applications where you might lose internet. The default by the way is 60 seconds so you do want to keep it low if you don’t expect loss of network. The other demo we looked at was what I call client side timeout. So this is really detecting if the users not not doing something and if you want to time them out. This uses the SUI idle plug in it’s available through the Web package manager and on GitHub repository. And what this does is it measures idle time down in the browser and this would be measured on things like if they’re moving the mouse or they’re touching a touch screen or they’re tapping on the keyboard. Actually what what you what events you want to capture and measure are up to you. I didn’t show that but but this is quite some configuration allowed. And it will also detect if the user is become idle or gone back you know gone back to being active or gone back to being idle and it’ll just give you a callback every time. Also if they have minimized or restored the window we saw that but all of this you can respond to with custom code. As you see fit and here’s what it looks like so again there’s a typo there should say just plug in sUI idle. But you call the on idle you pass in the callback and you can see down below that function on idle and that’s you do whatever you want so it’s really one line of code and then you’re calling your custom code. Again the real world use case for this is what I’ve seen anyway is that you have sensitive data so we work with a lot of. Applications that do a financial data or health care or other personal information and and you want to you want to leave that kind of unexposed so the moment that you think a user is no longer in front of their screen and keyboard or or phone. You want to quickly log them out and that’s the use case for this and you can just do that your discretion again with custom code. The third demo we saw was to show programmatic access to sessions so this was using the client manager plug in and this is to see across the whole application server and see all the sessions which are connected. And it allows you to get info about each session so we saw host name IP address username the application they’re logged into that sort of thing you can send messages to those clients if you want to. To say like you’re about to be disconnected or something like that. You can also have programmatic broadcast. Access and this is covered a prior webinar but you can really build up a. Almost like a peer to peer kind of communication protocol. But that’s a bit of a different topic. The code for it looks something like this you get the client manager plug in you get a list of connected clients then you can get information about them and maybe you decide you want to shut one down or send one a message. Then you just call those methods and again that’s the client manager plug in that ships by default you don’t have to install it separately it’s one of the default plug ins. So real world use case from what I’ve seen is typically like you want to have some custom enforcement of sessions so the default isn’t good enough and I’ve seen it typically by user and by tenant we say. This user can only log in one time otherwise you kick them out of their other session which is the one I shown or given the option to another one I’ve seen is is by tenant. Customers want to license their so we deal a lot with software vendors and Servoyand we want them to be able to enforce whatever licensing they want and what I hear sometimes is hey we this tenant pays for concurrency not for named users so they’re allowed to have. You know ten users on the system at one time how do I enforce the ten user rule well this is a great way to do it because you can add some custom info to the session we didn’t show this part but it’s pretty easy to do. It’s just a line of code add some custom info to a session and then you could say okay this tenant is logging in now get me all of the sessions that are already active for this tenant and if you see they fit their max then then you can do. that if you’re a software vendor and this is kind of where the rubber meets the road if you want to do that using that client manager plug in. Okay, I see some questions coming in so I’m going to ask you on to help me with that in the meantime I want to leave up this slide which gives us some information about Servoyworld if you haven’t taken that info down. Thanks for the great overview. Very briefly as you I mean the more advanced people in Servoyalready know that if you need to serve for you you may not know a lot of session management is for is done automatically for you like state management. So managing your state unlike in other many other way applications is kind of tough it’s sort of where you make that really easy and straightforward and transparent. I don’t even have to think about it at all because automatically for every user that is connected a server side state is managed where you can have data variables data sets security settings. And continue to run as the user is connected until they they timeout and how you timeout is was a big topic in this session. Couple of questions here one from my Gordon is the subload window that time out affected by the Tomcat session length. So in show as example can you set it for say three hours will Tomcat affect this. I believe that the this is kind of like a subset of that because a Servoy session is is kind of a a stateful envelope that gets initiated once you start a Servoy application. And whether or not it’s it’s considered to be connected is based on the web socket response. If if for some reason you have a session that is is still responding. Then I don’t think it will it will be overridden by the Tomcat timeout because that’s just sort of more like the HTTP session. So unless unless it was I can’t see a situation where where that would happen. Okay, yeah, there’s a question from him or is there a property within client manager plug in that can distinguish between ng or headless client. Yes, and I sort of I have that kind of in the code, but I didn’t point it out at all, so I can do that really quickly. So look at the example where I was loading those client sessions. There is one method on the in the plug in as you’re looping over the sessions here get application type. And that returns a constant which I’m going to just ask for code complete here because I can never remember application types and then you get one of these. So you know it’ll match one of those. So if it was if it was a non ng client and we have other client types. Then you could compare it and see which one it is. So definitely yes, but a question from Matt does the sky idle plug in work in smart clients to. No, no that’s that’s only for the ng client because it’s measuring activity in the browser. Okay, but I guess other ways in smart client to do it. I think I saw something on the forum some point in time. Yeah, I can’t remember. I think that there’s a plug in or something to measure that is a busy plug in or I can’t remember. Good. Alright, there’s a code from raffi that he’s using it already and it works great with web notifications. So let’s go to go to here from my raffi. Alright, guys, we’re five minutes later where you’re going to end this and we will post recording shortly as usual. So first on the YouTube channel and then later on to the websites archive where you can always watch these webinars when you’re coding or when you need some time out of your coding. So thanks all for attending, shall for presenting and we look forward to seeing you in about two weeks.

Close