Related topics

This topic presents conceptual and working information about the wwsto_api_session API package. Information is presented in these sections:

Introduction	Session visibility
Session object	Data consistency
Working with the session object	Lifetime of the session
Access to the data	Transactional behavior
Security

Introduction

The session storage API provides a server-side mechanism for storing temporary data and making the data available to other parts of an application. Oracle Portal automatically creates session storage for each module in an application, and for each user of the application. When the user's session ends, the data is automatically removed from the system in a form of garbage collection.

Server-side session storage reduces the need to use client-side mechanisms such as browser cookies or hidden HTML form fields to store this type of information.

Session storage allows you to:

• Store a value from one browser request and retrieve it in another request.

• Pass data across separate application pages.

• Store multiple values in different datatypes.

• Handle large numbers of users while avoiding naming conflicts. Every user logged in to an application created with Oracle Portal has a private session storage area that is completely secure and isolated from other users.

Session object

The session object is the unit of session storage for an application working in Oracle Portal. Developers may access this object to access and manipulate temporary data for the session the user is currently running.

Working with the session object

The general procedure for working with the session object is:

1. Load the session object, with an appropriate domain and sub-domain combination, using the load_session method.

2. Manipulate the content of the object using the set_attribute methods, or just access its content using the get_attribute methods.
   

3. Force these changes to be saved, using the save_session method.

Typically this sequence occurs within the scope of one client routine that extracts and/or sets all of the client states. For example:

declare

l_store portal30.wwsto_api_session;

l_date date;

begin

l_store := portal30.wwsto_api_session.load_session ('PORTAL', 'TEST');

l_store.set_attribute ('LAST_ACCESSED', sysdate);

l_store.set_attribute ('USERNAME', 'SMITH');

l_store.set_attribute ('COUNRTY_CODE', 1);

l_store.set_attribute ('LOCATION', 'US');

l_store.set_attribute ('LAST_LOGGED_ON', sysdate);

l_store.set_attribute_as_string('OFFICE_LOCATION', 'CALIFORNIA', 'US', 'STRING');

l_store.save_session;

end;

The login session that creates the session storage object is defined by wwctx_api.get_sessionid.

Access to the data

Attribute values within a session are stored in native form. For example, the attribute may have been defined to use the logical type CURRENCY, which has a native implementation type of NUMBER.

Functions within the session storage object permit setting and returning attribute values in either native form or in a string representation of the logical type.

The session storage methods access all of the functionality of the session storage object. These methods take the case-insensitive name of the attribute to set or get the perform the required action. For example:

The session storage methods access all of the functionality of the session storage object. These methods take the case-insensitive name of the attribute to perform the required action.

l_session.set_attribute ('testDate', sysdate);
dbms_output.put_line (l_session.get_attribute_as_date ('TeStDaTe'));

Security

Data in the session store is visible to all code that executes during a user's session. This includes Oracle Portal internal code as well as plug-in modules such as a provider, a plug, or the methods of a customer application. Due to the potential visibility to other code that might run during the user's session, data meant to be secure should not be stored in session storage.

Session visibility

The storage allocated by a session storage object is visible only within the scope of the login session that created it. Therefore, it is not possible for multiple users to share the same session, or for a single user operating multiple login sessions to access sessions across the login session boundary.

Data consistency

New or modified elements of the session storage are cached in memory until the save_session method is called. As a result, is is possible for a browser performing multiple simultaneous actions to see an inconsistent view of the data in session storage.

Session storage objects should be saved frequently. To guarantee consistency of the data, clients should re-load the session after every save. In addition, a save should be performed immediately after session attributes are created/modified.

Lifetime of the session

After creation, sessions exist until they are explicitly dropped by calling the drop_session method, or are implicitly dropped because the user logged off the system (either explicitly or implicitly).

It is the responsibility of the callers of the session storage object to ensure that any critical data is copied to more permanent storage before the session is removed.

Transactional behavior

Session storage uses the callers transaction scope to perform all loading and saving operations.

Version

Oracle Portal 3.0.6.6.5