Desktop Sessions

A desktop session is a user-related execution context on 4D Server or 4D single-user that does not result from any web or REST access.

Just like in a web user session, the code executed in a desktop session has access to a Session object which provides functions and properties allowing you to store session values and to share them between user processes, for example using the session.storage object.

However, unlike the code executed in web user sessions, the code executed in desktop sessions is not controlled by roles and privileges. It can access any parts of the 4D application, including ORDA and data model classes. On 4D Server, users and groups feature can manage user accesses.

You can nevertheless share a desktop session with a web session so that a desktop user can access your 4D application through a web interface, using for example Qodly pages and Web areas.

Session types

Desktop sessions include:

• Remote user sessions: In client/server applications, the session that manages the user processes on the server.
• Stored procedures sessions: In client/server applications, the unique virtual user session that manages all stored procedures executed on the server.
• Standalone sessions: Local session object returned in single-user application (useful in development and test phases of client/server applications).

nota

Keep in mind that Web sessions are used as soon as the 4D project is accessed through web or REST requests and scalable sessions are enabled.

The following diagram shows the different session types and how they interact:

Remote user sessions

On the server, in "user processes" (i.e. processes related to remote users), the Session command returns a session object describing the current user session. This object is handled through the functions and properties of the Session class.

nota

On a remote 4D, the session object always returns null.

Related blog posts

4D remote session object with Client/Server connection and Stored procedure.

Usage

The session object allows you to handle information and privileges for the remote user session.

You can share data between all processes of the user session using the session.storage shared object. For example, you can launch a user authentication and verification procedure when a client connects to the server, involving entering a code sent by e-mail or SMS into the application. You then add the user information to the session storage, enabling the server to identify the user. This way, the 4D server can access user information for all client processes, enabling customized code to be written according to the user's role.

You can also assign privileges to a remote user session to control access when the session comes from Qodly pages running in web areas.

Availability

The remote user session object is available from:

• Project methods that have the Execute on Server attribute (they are executed in the "twinned" process of the client process),
• Triggers,
• ORDA data model functions (except those declared with the local keyword),
• Database methods such as On Server Open Connection and On Server Close Connection.

Stored procedure sessions

On the server, all stored procedures share the same virtual user session.

Usage

You can share data between all processes of a store procedure session using the session.storage shared object.

Availability

The session object of stored procedures is available from:

• Project methods that are called by the Execute on Server command,
• ORDA data model functions called from a stored procedure,
• Database methods such as On Server Startup and On Server Shutdown.

Standalone sessions

A standalone session is the single-user session running when you work locally with 4D.

Usage

The standalone session can be used to develop and test your client/server application and its interaction with web sessions and OTP sharing. You can use the session object in your code in standalone session just as the session object of the remote sessions.

Availability

The session object of a standalone is available from all methods and code executed on the 4D application.

Sharing a desktop session for web accesses

Desktop sessions can be used to handle web accesses to the application by the same user and thus, manage their privileges. This possibility is particularly useful for Client/Server applications where Qodly pages are used for the interface, running on remote machines. With this configuration, your applications have modern CSS-based web interfaces but still benefit from the power and simplicity of integrated client/server development. In such applications, Qodly pages are executed within standard 4D Web areas.

To manage this configuration in production, you need to use remote user sessions. Actually, requests coming from both the remote 4D application and its Qodly pages loaded in Web areas need to work inside the same session. You just have to share the session between the remote client and its web pages so that you can have the same session storage and client license, wherever the request comes from (web or remote 4D).

Note that privileges should be set in the session before executing a web request, so that the user automatically gets their privileges for web access (see example). Keep in mind that privileges only apply to requests coming from the web.

You can develop this configuration in your 4D Developer application (single-user): you can use the standalone session to code and test all features related to web access, whether your application is intended for single-user or client/server deployment.

Shared sessions are handled through OTP tokens. After you created an OTP token for the desktop session on the server or on the single-user 4D application, you add the token (through the $4DSID parameter value) to web requests sent from Web areas containing Qodly pages (or from any web browser) so that the user session on the server or the single-user application is identified and shared. On the web server side, if a web request contains an OTP id in the $4DSID parameter, the session corresponding to this OTP token is used.

nota

When creating an OTP token in client/server environment, you need to execute the OTP creation code on the server (the Session object is Null on a remote 4D). You can use for example the On Server Open Connection database method.

Related blog post

Embed Qodly pages in a 4D web area without extra cost

Example

In the On Server Open Connection database method:

var $otp : Text

// Some privileges are put in the remote user session on the server for a further web access
resetPrivileges("basic")

// An OTP is created on the server for this remote client session
$otp:=getOTP


// The user has already the required privileges for a web access
// and the same session is shared between this remote user and the web Qodly app
WA OPEN URL(*; "Welcome"; "http://127.0.0.1/$lib/renderer/?w=People&$4DSID="+$otp)

resetPrivileges project method:

// This function is run on the server
// and puts some privileges in the session for a further web access

#DECLARE ($priv : Text) 
	
Session.clearPrivileges()
Session.setPrivileges($priv)

getOTP project method:

// This project method is run on the server 
// and generates an OTP able to retrieve this remote user session 

#DECLARE : Text 
	
return Session.createOTP()