Discussion

Active Connections List shows logged out users

We want to get an accurate list of who's logged in to a system.
We're in v5.5.

Looking at the Developer Portal's Active Connections list, I see some logged out users.
When I look at the Requestors list on the SMA, I see a column "last input". (typically the last activity invoked). For some users this shows Activity=Code-Security.LogOff and Activity=Data-Portal.FreeClipboard -- these look like the last actions before logoff.

So ideally I'd like to filter or sort this list. I can't do it in SMA. It's seems like we can in the ListView. The ListView calls activity RequestorsOnline, which calls the PegaAPI method pega.getConnectionsList(myStepPage). Yet in the results I only see a handful of properties; none of them showing anything resembling the last activity invoked.

Any ideas?

Thanks,

Jon

**Moderation Team has archived post**

This post has been archived for educational purposes. Contents and links will no longer be updated. If you have the same/similar question, please write a new post.

Comments

Keep up to date on this post and subscribe to comments

August 2, 2010 - 2:30pm

In January, I wrote: "What was Pega's intent here? Should this activity [LogOff] be final or not? If it is final, how can we address the problem of closing the requestor when all threads are stopped?"

LogOff is not final in v6.1, so I conclude that Pega's intent in v5.5 was not to make it final.

Jon

January 21, 2010 - 4:28pm

On the 11th hour, of the 11th day, of the 11th month, of last year, I wrote: "Looking at the Developer Portal's Active Connections list, I see some logged out users. When I look at the Requestors list on the SMA, I see a column 'last input'. (typically the last activity invoked). For some users this shows Activity=Code-Security.LogOff..."

I had a hunch and had a look at Code-Security.LogOff. Here's step 1:
[code]
// If this is not one of the 'main' Threads, just stop it and close the current window.
if (curThread.equals("Developer") || curThread.equals("STANDARD") ||
curThread.indexOf("/$Developer") > -1 ||
curThread.indexOf("/$STANDARD") > -1) {
pega.getAuthenticationHandle().unauthenticate();
}
[/code]

In our configuration, the thread name is the same as the access group (allowing the user to access multiple apps from the same corporate portal). Thus, a better algorithm here would be to check the Set returned by tools.getRequestor().getThreadNames(). If there is only one item in this Set, then unauthenticate.

We could test this by overriding Code-Security.Logoff -- it's not final, after all.
But there's one catch -- @baseclass.Logoff (which calls the Code-Security version) *is* final.

What was Pega's intent here? Should this activity be final or not? If it is final, how can we address the problem of closing the requestor when all threads are stopped?

Jon

August 22, 2013 - 11:44am

For those of you scoring at home, this assumption has been corrected in v6... (at least in v6.2/sp2)

Code-Security.LogOff calls unauthenticate() for every thread except OpenPortal.

 

// If this portal was spawned from another portal and is not the primary one then don't unauthenticate
if (curThread.equals("OpenPortal")) {
    nextBlock = "A";
} else {
    pega.getAuthenticationHandle().unauthenticate();
}

June 27, 2014 - 10:51am

Hey Jonny,

 

we are planning to track total number of concurrent users at a given time. We can use pega.getConnectionsList(myStepPage) step but it might consume lot of page memory if the requestors are around 1000. We just need total number of browser requestors. Do PegaAPI has any function call instead of populating all users list?

 

Appreciate your support.

 

Thanks,

Kowsik