Applies to Pega Platform 7.2-8.7
This article provides answers to frequently asked questions related to Session Management.
Answers to frequently asked questions
What is the default context of a browser requestor that is created?
How to override the default AccessGroup for a new requestor that is unauthenticated?
I click Pega URL without logging into the Pega application. When do the Unauthenticated requestors get deleted?
How does the context of a requestor change?
Can a requestor execute multiple requests simultaneously?
What happens on clicking Pega URL, https://localhost:1080/prweb, for the first time?
What happens on clicking Pega URL when Authenticated requestor is sent as part of the Pega-RULES cookie?
What is a NodeCrash scenario?
How does the AccessGroup Timeout work?
How to passivate requestor or thread or pages?
What is the default context of a browser requestor that is created?
Context for a requestor is set using AccessGroup. Browser requestors are set to PRPC:Unauthenticated AccessGroup by default.
How to override the default AccessGroup for a new requestor that is unauthenticated?
The default AccessGroup is from the <SystemName>!BROWSER Requestor type.
Perform the following steps to override the default AccessGroup:
- Access the RequestorType instance by navigating to SysAdmin > Requestor type.
- Update the value defined in the Requestor type.
I click Pega URL without logging into the Pega application. When do the Unauthenticated requestors get deleted?
The shortTimeOut setting is set to True for the Unauthenticated requestors. The default value of shortLivedRequestorTimeoutInMillies is 60 seconds.
MasterForRequestors Daemon runs in the background and deletes the Unauthenticated requestors when they time out.
How does the context of a requestor change?
The context of a requestor is defined based on AccessGroup. Initially, a new requestor is created with Unauthenticated AccessGroup. However, the context changes after the authentication.
Context also changes during the following scenarios:
- Switch Application
- RedirectAndRun
- Change in AccessGroupHash in the top URL
Can a requestor execute multiple requests simultaneously?
No, each request is executed after acquiring lock on the requestor.
What happens on clicking Pega URL, https://localhost:1080/prweb, for the first time?
The following flow is executed when you click the Pega URL (https://localhost:1080/prweb) without any Pega-RULES cookie:
- New requestor (for example, Requestor1) is created with Unauthenticated AccessGroup and the encrypted value of the requestor, Requestor1, is sent to the server side as the Pre-atn cookie. URL is redirected with the Unauthenticated AccessGroup (AG) hash and the STANDARD thread name.
Example: https://localhost:1080/prweb/app/default/beEBp4uRVTogorRwSwWqbOtn9IL2fw… - Enter the Credentials. Credentials are validated and the requestor is authenticated. You are redirected with Authenticated AG hash.
Example: https://localhost:1080/prweb/app/PegaRULES_/pbdorj4V2aBoI4ScEONLsEaxdEW…
Cookie is set to Authenticated cookie. - Click .
a. Code-Security.LogOff activity is executed.
b. Locks held by requestor are released.
c. Requestor is unauthenticated. All the properties on the requestor except the Guest properties, are removed. Application specific data is also removed.
d. Unauthenticated cookie is set in the response. You are redirected to Code-Security.EndSession. - The Code-Security.EndSession activity is executed.
a. Requestor is destroyed.
b. Pega-RULES cookie value is set to None. This is in response to Max-Age set to 0.
The following or the next request does not contain the Pega-RULES cookie. Hence, it is considered as a fresh request.
What happens on clicking Pega URL when Authenticated requestor is sent as part of the Pega-RULES cookie?
The following flow is executed on clicking the Pega URL and sending the Authenticated requestor as part of the Pega-RULES cookie:
- Requestor ID is read from the cookie. Attempt to find the requestor in the following order:
a. Attempt to find an active requestor that is present on the current node with the same Requestor ID.
b. If the requestor is not found, then verify if another requestor with the same ID is already present in the Passivated state.
c. If the requestor is not found, then the Remote Execution request is sent to all the nodes in the cluster to verify if the requestor is present in another node.
d. If the requestor is present in another node, then the requestor is force passivated on that node and activated on the current node.
e. If the requestor is still unavailable, then the NodeCrash scenario is executed.
What is a NodeCrash scenario?
The following is an example of a NodeCrash scenario:
- User’s requestor is destroyed while working on the Pega Dev Studio.
- User refreshes the Dev Studio that triggers multiple parallel requests. All the requests reach server with the authenticated requestor ID (for example, Req1 as Pega-RULES cookie).
- User creates a new requestor (Req2) and maps it to the old or the previous Requestor ID (Req1) so that multiple requestors are not created.
- User is redirected to the Login screen.
How does the AccessGroup TimeOut work?
Configure TimeOut for AccesGroup by navigating to Advanced > AccessControl > Authentication TimeOut in the AccessGroup instance.
Any requestor that is idle for more than the configured TimeOut value is marked as TimedOut and is prompted for credentials.
Requestor is marked as TimedOut if a new request is triggered after the session is idle for the TimeOut value configured.
How to passivate requestor or thread or pages?
MasterForRequestor Daemon runs in the background and verifies if requestors or threads or pages were idle for more than the configured TimeOut value. They will be added to the Passivation queue if they were idle for more than the configured time. Passivation Daemon takes care of Passivation.
The following table represents the default TimeOut configuration for passivation:
| Requestor Type | Setting Name | Default Value |
| Application (app requestor) | timeout/application | 600 seconds (10 mins) |
| Batch (batch requestors) | timeout/batch | 60 seconds (1 min) |
| Browser (browser requestors) | timeout/browser | 3600 seconds (60 mins) |
| Thread (PRThread) | timeout/thread | 1800 seconds (30 mins) |
| Page (Clipboard pages) | timeout/page | 900 seconds (15 mins) |
| Portal (portal requestors) | timeout/portal | 3600 seconds (60 mins) |
| Other (all other requestors) | timeout/other | 300 seconds (5 mins) |
Related content
Profiling your requestor session
Transition sessions from unauthenticated to authenticated (8.2)