Initializing a client-principal object for a multi-tier application
- Last Updated: October 17, 2024
- 3 minute read
- OpenEdge
- Version 12.8
- Documentation
The code examples in this section show two approaches to initializing the client-principal object for a multi-tier application. Both examples test for the application server operating mode and both add the sealed client principal to a database that stores session context. The examples differ in the way the client-principal object is accessed.
The following code fragment shows the use of the GetClientPrincipal ( ) method
to access an unsealed client-principal object. The client-principal
object is created in a Progress.Lang.OERequestInfo instance. OERequestInfo is
automatically initialized when a CREATE SERVER statement
executes on an ABL client and can be referenced using the attributes
of the SESSION system handle.
The following code fragment also shows the use of the SetClientPrincipal ( ) method
to store a deep copy (clone) of the client principal in the OERequestInfo instance
after either the success or failure of authentication.
Client principal initialization using GetClientPrincipal ( ) and SetClientPrincipal ( ) methods
|
The next code fragment shows the use of the IMPORT-PRINCIPAL ( ) and EXPORT-PRINCIPAL ( ) methods
for initializing the client-principal object. Using these methods
requires that the client-principal object is explicitly created
in the code, rather than referenced as an attribute of the SESSION system
handle, as in the previous example. Also note, that in this case
the client-principal object is passed as a parameter rather than
referenced as an attribute.
Client-principal initialization using the IMPORT-PRINCIPAL ( ) and EXPORT-PRINCIPAL ( ) methods
|
For the state-free and stateless operating modes, both code fragments set the
SESSION-ID attribute to the ClientContextId property value obtained from the OERequestInfo object returned by the CURRENT-REQUEST-INFO attribute on the SESSION
system handle. This property is automatically initialized with a GUID value when the client
initially creates the server handle to access the authentication server. This ClientContextId property value, as well as the sealed
client-principal set on the CURRENT-RESPONSE-INFO handle in
the first example, remain unchanged during all subsequent requests from the client to the
application server (using the same server handle) unless either the client or the
application server change them.
A stateless application service can also identify each request by the client
connection and key a context store using the SERVER-CONNECTION-ID attribute on the SESSION
system handle. However, it also needs a unique value to set the SESSION-ID attribute in the client-principal for auditing purposes. Because the
same ClientContextId property value is both globally unique
and can be easily passed between sessions, the management of stateless context can be
simplified by using this one value for both purposes instead of creating a separate unique
value for auditing with the ABL GENERATE-UUID function.
This one inter-session value ensures that a unique user login session auditing record is
recorded across all possible application server sessions and can also be used to key a
context store for the login session.
Both stateless and state-free application services must manage
user context in order to export, store, retrieve, and import different
client-principal objects between client requests. In releases prior
to OpenEdge 11.0, but they must do it differently according to their
respective session-managed and session-free behavior. With Release
11.0, application services running in either operating mode can
take advantage of the same ClientContextId property
mechanism.
However, the SESSION:SERVER-CONNECTION-ID attribute
and GENERATE-UUID function mechanisms continue
to work for stateless operating mode. The following sections provide
more detail using different examples on how to manage identity for
both stateless and state-free application services.