End Session programmatically

Question

Question

Michoel Reach · Mar 31, 2021

We have a background job that keeps an eye on our ongoing CSP sessions, counts licenses used and some other tasks. Question: If I know the session ID (something like "wuuZ2Gwgxw"), how do I (find and) end that particular session programmatically in ObjectScript - i.e., the equivalent of %session.EndSession=1 in the csp page code?

Thanks!

Michael Reach

Product version: Caché 2018.1

$ZV: Cache for Windows (x86-64) 2018.1.4 (Build 505_1_20258U) Thu Sep 10 2020 10:22:22 EDT

Discussion (15)0

Log in or sign up to continue

Vitaliy Serdtsev · Apr 1, 2021

Try the following:

s status=$$DeleteSession^%SYS.cspServer("wuuZ2Gwgxw")

This is not documented or supported. Use at your own risk.

But since you specified Caché 2018.1, which is no longer being developed so not may change in the future (not counting security patches).

1 0

score 0 · Answer 1 · 2021-03-31T13:32:57-04:00

Eduard Lebedyuk · Mar 31, 2021

What are the triggers for a session closure?

0 0

score 0 · Answer 2 · 2021-03-31T16:45:30-04:00

Sorry, could you explain what you mean by this? If you mean, when would we want to end a session, the answer is that we have been getting a lot of CSP sessions created by pings on the web page from the outside. Someone from who-knows-where calls the web page, a session is created and it uses a license until the grace period expires 20 minutes later. If half-a-dozen of them happen at once (which has been happening), we're out of licenses.

So we were trying to look over the license usage each minute, check each of the licenses associated with a CSP type, and end the session if that user never actually logged in.

score 0 · Answer 3 · 2021-03-31T14:08:45-04:00

This is for educational use only, so if you break your system, lose your cat, or your ice cream goes all melty by using my example below, please don't hold me accountable.

Also, I would like to mention that I borrowed the base structure from the ^%SS utility in the %SYS namespace.

I would also like to mention that in my *very* limited testing, you'll only have a CSP Session ID while there's actually "stuff" going on in the CSP Page. If you're executing a two-minute query in a CSP Page, whilst that query is running you can see (and clobber) that session. If the query is complete and you're just scrollin' round the results not generating new HTTP requests into the CSP Page, you may not be able to see the CSP Session ID.

That said, this did work for me to kill a CSP Session mid-query:

 ZZPROCKILL ; 
 S OLDNS=$NAMESPACE
 S $NAMESPACE="%SYS"
 s query="",parm=1
 Set Rset=##class(%Library.ResultSet).%New("SYS.Process:SS")
 Do Rset.Execute(parm)
 s POP=0
 While Rset.Next() {
s Username=Rset.Get("User")
CONTINUE:Username'="UnknownUser"
s NameSpace=Rset.Get("Namespace")
i NameSpace="" s NameSpace="%SYS" 
; i (Dir'=""),(NameSpace'=Dir) continue
Set Pid=Rset.Get("Process")
s Process=##CLASS(%SYS.ProcessQuery).Open(Pid)
S SID=Process.CSPSessionID
D Process.%Close()
w !,$J($s(($zversion(1)=1):$ZH(+Pid),1:Pid),8)_$Case(JobType,1:"*",:""),?20,Username,?40,NameSpace,?50,SID,!
    i SID'="" d $SYSTEM.Process.Terminate(Pid)
 }
 D Rset.%Close()
 
 S $NAMESPACE=OLDNS
 Q
 ;

I have 'embiggened' the line of code that actually terminates the process, and I did make one further assumption in my code: That the CSP Sessions would be run under the user: UnknownUser - If your system uses a different user to execute CSP, you'll need to change the username in the CONTINUE: line (ZZPROCKILL+10).

If you want to just see if you can find CSP sessions and not actually terminate them, comment out that final 'embiggened' line in the While loop (that starts with i SID'="").

Hope this helps!

score 0 · Answer 4 · 2021-03-31T16:48:56-04:00

Michoel Reach Mar 31, 2021 to Roger Merchberger

Thank you! Does this reclaim the license as well? Is any other cleanup required?

Michael

0 0

score 0 · Answer 5 · 2021-03-31T16:48:36-04:00

I notice that you aren't actually doing the lookup by session id, just looking at all the system processes there are. Does that mean that there isn't really any way to do this on the session level?

Michael

score 0 · Answer 6 · 2024-08-28T15:19:31-04:00

Norman W. Freeman Aug 28, 2024 to Roger Merchberger

This is brutal. Fortunately you put a disclaimer.

0 0

score 0 · Answer 7 · 2021-04-01T08:23:04-04:00

Michoel Reach Apr 1, 2021 to Vitaliy Serdtsev

Wow, cool! Thanks!

Michael

0 0

score 0 · Answer 8 · 2021-04-01T09:07:58-04:00

If I could ask, does this reclaim the license used for the CSP session, or is there another step that does that quickly?

Thanks!

score 0 · Answer 9 · 2021-04-02T01:35:59-04:00

It is better to check this with your license, as it is likely that some of its options, such as Web Add-on, may affect this (see $SYSTEM.License.PublicWebAppUser).

score 0 · Answer 10 · 2024-08-28T15:18:08-04:00

Norman W. Freeman Aug 28, 2024 to Vitaliy Serdtsev

I found this command too, but it does not work, I got :

 ERROR #921: Operation requires %DB_IRISSYS:WRITE privilege

0 0

score 0 · Answer 11 · 2021-04-01T13:34:52-04:00

I was curious.
What problem do you hope to solve by deleting the section?
Is there a section that may have frozen? Or is the normal expiration time not long enough?

score 0 · Answer 12 · 2021-04-01T15:02:08-04:00

We are getting hits from random IP addresses around the world, a few times a week. They ping the page and then never proceed further, never log in (they wouldn't be able to without an account). We get half-a-dozen hits within a few seconds, using up half-a-dozen licenses - we only have 14, and several more are used anyhow by the system. Those session persist for twenty minutes because of the Grace period for our CSP pages. When that happens, it is very likely that some of our own users will be unable to log in because all the licenses are gone.

We try to stop them at the firewall, but it's new IP addresses every time, and anyone can go to our website.

So what I wanted to do was check the license logging every minute, see which sessions are from IPs that never tried to log in, say after a minute, and get rid of them. That way we get the license(s) back. I have working code that identifies those sessions.

If I were coming from a CSP page itself, I would do something like

s %session.EndSession=1
k %session.Data
d %session.Logout()
But that won't work from an outside job: I need to be able to access the right session. That's all I'm trying to do: get access to the correct %CSP.Session object.

score 0 · Answer 13 · 2021-04-02T04:20:00-04:00

I understood that 14 licenses + Grace Period are your biggest pains.
In past, I decreased the risk by moving ALL (suspicious) connections to a dedicated User
observing his maxConnection limit using %CSP.Session.Login() especially this explanation:

Login with this username and password, returns a status code to show if it worked or not. This method also trades license units at the same time so this CSP session will be logged in as a named user. If you pass type=1 then this will trade licenses only and not login as this user.

This can't avoid a DDoS attack but it limits the initial impact and allows you to
protect some emergency licenses.

[As I know the inventor of Grace Period since it was rolled out with a lot of pain for customers
I'm not willing to discuss this "feature" in public again]

score 0 · Answer 14 · 2024-08-28T15:47:35-04:00

Just FYI, CSP sessions are instances of %CSP.Session. You could do ##class(%CSP.Session).%OpenId("wuuZ2Gwgxw") to get the session and use some of the properties and functions there to get more information on what's going on. And since they extend %Persistent, you can also use %DeleteId (at your own risk, of course).