Question
Tech Mahindra
CA
Last activity: 9 May 2016 1:40 EDT
Is it possible to unathenticate any operator conditionally?
We are using prpc 6.1 SP2. We have a requirement where same operator cannot be used across multiple machines at the sametime. While authenticating, if it is determined that the current operator is being logged in already, system should unathenticate the first requestor. We are using external authentication service. Is it possible to unathenticate any operator conditionally?
Accepted Solution
Tech Mahindra
CA
Got the below code and which will suffice the requirement to kill the requestor of the specific node.
/******Use below code check the list of active requestors*****/
/******The list of active requestors will be displayed in log file in XML format******/
Object test = com.pega.pegarules.priv.management.MBeanManagement.executeMBeanOperation("com.pega.pegarules.management.internal.RequestorManagement","RequestorList",null,null,null);
//oLog.infoForced("test"+test);
// test is an instance of string , for any string operations please type cast test to String object.
/******Use below code to stop/kill the requestor*****/
test = com.pega.pegarules.priv.management.MBeanManagement.executeMBeanOperation("com.pega.pegarules.management.internal.RequestorManagement","StopRequestor","H0DADAD0A8BEC9BEACFAD43B31C04FBC9",null,null);
oLog.infoForced("test"+test);
Pegasystems Inc.
IN
Hi
This forum discussion can be a good start : https://pdn.pega.com/forums/security/prevent-multiple-login
Also worth checking this guide which talks about authentication in details : https://docs-previous.pega.com/authentication-pegarules-process-commander-prpcv52
Tech Mahindra
CA
How do we get the requestor/thread details of an existing user to kill/Unauthenticate it? We see example of Logoff method where it is fetching current thread and unauthenticating. Do we have any OOTB java methods to fetch the existing requestor?
Pegasystems Inc.
IN
Another idea would be to try utilizing the OOTB listview "RequestorsOnline"
This listview returns the list of operators / connectors currently active.
You can do a matching of the user who tries to log in with the result of this listview to determine whether there is any existing users with same name or not
Once confirmed, then you can add some more steps on your activity which can unauthenticate the user. For detail on the unauthentication, you can refer the logoff activity.
Hope this helps.
Tech Mahindra
CA
Thanks Santanu.
I tried initially RequestorsOnline listview but it is fetching active requestors of only particular node but we need to get the requestors of all nodes. So we went for the new table creation to get the list of all active requestors.
In Logoff activity current thread is stopped. For Logoff of other requestors, is there any method to get the thread of that requestor?
Pegasystems
US
One thing you might want to do is model your design very similarly to the lock-work-object design.
You can start by logging in and opening an assignment on the normal perform harness, and then attempt to log in a second time as same operator and open the same assignment. You will observe all of the following features when you do that, which are already-implemented out-of-box features :
1) The second person will not be able to open the same assignment initially because first person has it locked [ for your authentication needs, this is equivalent to not letting same person log in a second time ]
2) Second person will be given the option of causing first operator to be logged out so lock is released so second person can lock the work [ for your authentication needs, this is equivalent to logging out first person so second person can proceed under same operator name ]
Note that the above scheme handles two different cases, which you will be interested in for your authentication needs, namely the case where the two logins are on the same node and the case where they are in different nodes. For this second case, the pulse is involved in telling the other node to do the actual work of logging out the operator.
One thing you might want to do is model your design very similarly to the lock-work-object design.
You can start by logging in and opening an assignment on the normal perform harness, and then attempt to log in a second time as same operator and open the same assignment. You will observe all of the following features when you do that, which are already-implemented out-of-box features :
1) The second person will not be able to open the same assignment initially because first person has it locked [ for your authentication needs, this is equivalent to not letting same person log in a second time ]
2) Second person will be given the option of causing first operator to be logged out so lock is released so second person can lock the work [ for your authentication needs, this is equivalent to logging out first person so second person can proceed under same operator name ]
Note that the above scheme handles two different cases, which you will be interested in for your authentication needs, namely the case where the two logins are on the same node and the case where they are in different nodes. For this second case, the pulse is involved in telling the other node to do the actual work of logging out the operator.
IN FACT, you may want to consider as a design for your authentication needs to merely have a per-operator assignment whose only purpose is to provide a one-operator-per-cluster token. The work would be locked when the operator logs in, and that lock would be the way you use both for guaranteeing that the operator is only logged in once, and facilitating for killing the first login so the second one can log in. /Eric
Tech Mahindra
CA
Thanks a lot Eric.
2) Second person will be given the option of causing first operator to be logged out so lock is released so second person can lock the work [ for your authentication needs, this is equivalent to logging out first person so second person can proceed under same operator name ]
Note that the above scheme handles two different cases, which you will be interested in for your authentication needs, namely the case where the two logins are on the same node and the case where they are in different nodes. For this second case, the pulse is involved in telling the other node to do the actual work of logging out the operator.
Is there any OOTB functionality to logoff the user (get the requestor details using pyUserIdentifier to kill it)? I see LogOff activity which actually unauthenticate the current requestor but how to kill first requestor from second logon window?
Tech Mahindra
CA
Hi,
Is there any OOTB functionality to logoff the user (get the requestor details using pyUserIdentifier to kill it)? I see LogOff activity which actually unauthenticate the current requestor but how to kill first requestor from second logon window?
Tech Mahindra
CA
Hi Team,
We are advised to display 2 links when the same user already logged on to the application in the same machine and again trying to logon new session
1. Close the window and continue in the last session
2. Logoff the existing session and continue with new session
Again it comes to main question, how to identify and unathenticate existing user session when option 2 is selected above? Appreciate your suggessions.
Accepted Solution
Tech Mahindra
CA
Got the below code and which will suffice the requirement to kill the requestor of the specific node.
/******Use below code check the list of active requestors*****/
/******The list of active requestors will be displayed in log file in XML format******/
Object test = com.pega.pegarules.priv.management.MBeanManagement.executeMBeanOperation("com.pega.pegarules.management.internal.RequestorManagement","RequestorList",null,null,null);
//oLog.infoForced("test"+test);
// test is an instance of string , for any string operations please type cast test to String object.
/******Use below code to stop/kill the requestor*****/
test = com.pega.pegarules.priv.management.MBeanManagement.executeMBeanOperation("com.pega.pegarules.management.internal.RequestorManagement","StopRequestor","H0DADAD0A8BEC9BEACFAD43B31C04FBC9",null,null);
oLog.infoForced("test"+test);