7.17. Session Store¶

7.17.1.1. Save destination of session variables can be selected¶

Save destination of the session variable can be selected according to the usage.

The following three types of stores are provided as standard.

• DB store
• HIDDEN store
• HTTP session store

For the features and selection criteria of the session store, see Features and selection criteria of session store.

Also, Redis can be used as a store destination by using Redis Store (Lettus) Adapter.

7.17.1.2. Serialization mechanism for session variable can be selected¶

The serialization mechanism when saving session variables in session store can be selected from the following. For details of each function, refer to the linked Javadoc.

• serialization by Java standard serialize (default)
• serialization and encryption by Java standard serialize
• XML-based serialization with JAXB

7.17.3.1. Save target must Java Beans object that can be serialized¶

Object to be saved in the session store must be a serializable Java Beans object.

The property type of the object must be a Java basic type or a Java Beans object that can be serialized. Arrays and collections can also be used for properties.

7.17.4.1. Configure for using session store¶

To use session store, configure SessionManager in the component definition in addition to configuring Session Variable Store Handler.

The following is a configuration example when all the save destinations provided as standard are used.

<!-- Configure with the component name "sessionManager" -->
<component name="sessionManager" class="nablarch.common.web.session.SessionManager">

  <!--
    Store name used by default if a save destination is not specified explicitly
  -->
  <property name="defaultStoreName" value="db"/>

  <!-- Add components according to the save destination used in the application -->
  <property name="availableStores">
    <list>
      <!-- HIDDEN store -->
      <component class="nablarch.common.web.session.store.HiddenStore">
        <!-- See Javadoc for details of the configuration value -->
      </component>

      <!-- DB store -->
      <component-ref name="dbStore" />

      <!-- HTTP session store -->
      <component class="nablarch.common.web.session.store.HttpSessionStore">
        <!-- See Javadoc for details of the configuration value -->
      </component>
    </list>
  </property>
</component>

<component name="dbStore" class="nablarch.common.web.session.store.DbStore">
  <!-- See Javadoc for details of the configuration value -->
</component>

<!-- DB store initialization configuration -->
<component name="initializer"
    class="nablarch.core.repository.initialization.BasicApplicationInitializer">
  <property name="initializeList">
    <list>
      <!-- Other components are omitted -->
      <component-ref name="dbStore" />
    </list>
  </property>
</component>

When using DB store, a table must be created in the database to store the session variables.

The definition of the table to be created is shown below.

USER_SESSION table

Column name	Data type
SESSION_ID(PK)	java.lang.String
SESSION_OBJECT	byte[]
EXPIRATION_DATETIME	java.sql.Timestamp

SESSION_ID should be defined as VARCHAR instead of CHAR as it may not work properly in Oracle.

The table name and column name can be changed. To change, define the components of UserSessionSchema to DbStore.userSessionSchema.

<property name="userSessionSchema">
  <component class="nablarch.common.web.session.store.UserSessionSchema">
    <!-- See Javadoc for details of the configuration value -->
  </component>
</property>

7.17.4.2. Hold the input information between the input-confirm-complete screens¶

To retain the input information between the input-confirm-complete screen, use the session store depending on whether screen operations on multiple tabs are allowed.

When screen operations on multiple tabs are not allowed

Hold session variables in a table on the database using the DB store.

When screen operations on multiple tabs are allowed

Hold session variables in the client using HIDDEN store.

When using HIDDEN store, use hiddenStore tag in JSP of input/confirmation screen as shown below.

<n:form>
  <!--
    Configure the value of parameterName property of HiddenStore
    defined in the component configuration file to the name attribute
  -->
  <n:hiddenStore name="nablarch_hiddenStore" />
  <!-- Other tags are omitted -->
</n:form>

Implementation example of session store between input-confirm-complete is shown below.

7.17.4.3. Holds credentials¶

Use DB store to retain credentials.

Implementation example of session store during login/logout is shown below.

Login to the application

// Change session ID before login
SessionUtil.changeId(ctx);

// Regenerate CSRF token (If you are using the CSRF Token Verification Handler)
CsrfTokenUtil.regenerateCsrfToken(ctx);

// Save login user information in session store
SessionUtil.put(ctx, "user", user, "db");

Logout from the application

// Invalidate the entire session store
SessionUtil.invalidate(ctx);

7.17.4.4. Refer to the session variable value from JSP¶

The value of session variable held in the session store can be referenced from JSP using the same procedure as the normal request scope and session scope.

7.17.4.5. Customize the encryption configuration of the HIDDEN store¶

The default encryption/decryption configuration of the HIDDEN store is as follows.

When application servers are made redundant, different keys are generated for each application server, and decryption may fail. In this case, the encryption/decryption key is set explicitly.

The following is a configuration example in which AES is used as the encryption algorithm and the encryption/decryption key is configured explicitly.

<component class="nablarch.common.web.session.store.HiddenStore">
  <!-- Other configuration values are omitted -->
  <property name="encryptor">
    <component class="nablarch.common.encryption.AesEncryptor">
      <property name="base64Key">
        <component class="nablarch.common.encryption.Base64Key">
          <property name="key" value="OwYMOWbnLyYy93P8oIayeg==" />
          <property name="iv" value="NOj5OUN+GlyGYTc6FM0+nw==" />
        </component>
      </property>
    </component>
  </property>
</component>

Point

For the encryption key and IV, set base64-encoded values. To increase the key strength, the following functions may be used to generate the key and IV.

• Generate the key using KeyGenerator.
• Generate IV using SecureRandom.

Using Base64Util or java.util.Base64.Encoder, which is added in Java 8, is better for base64 encoding.

7.17.4.6. Specify the transition destination screen when the value does not exist in the session variable¶

Session variables always exist in normal screen transitions, but in some cases, session variables that originally existed may not be accessible due to incorrect screen transitions being performed using the back button of the browser. Since an exception indicating that the session variable does not exist ( SessionKeyNotFoundException ) is thrown, transition to an arbitrary error page is possible by catching this exception.

The realization method is shown below.

Transition to a common error page in the system

When transitioning to a common error page in the system, catch the exception in the handler and specify the transition destination.

Implementation examples

public class SampleErrorHandler implements Handler<Object, Object> {

  @Override
  public Object handle(Object data, ExecutionContext context) {

    try {
      return context.handleNext(data);
    } catch (SessionKeyNotFoundException e) {
      // Catches the exception indicating that the session variable does not exist
      // and returns the error page indicating the incorrect screen transition
      throw new HttpErrorResponse(HttpResponse.Status.BAD_REQUEST.getStatusCode(),
              "/WEB-INF/view/errors/BadTransition.jsp", e);
    }
  }
}

Specify the transition destination for each request

When switching the transition destination for each request, specify the transition destination using OnError Interceptor. Note that the transition destination can be changed for only some of the requests by using it together with the transition to a common error page in the system mentioned above.

Implementation examples

// Specify the transition destination for each request
// by specifying the exception indicating that the session variable does not exist
// in the target exception
@OnError(type = SessionKeyNotFoundException.class, path = "redirect://error")
public HttpResponse backToNew(HttpRequest request, ExecutionContext context) {
  Project project = SessionUtil.get(context, "project");
  // Process is omitted
}

7.17.5.1. Add the save destination of session variables¶

The following steps are required to add the save destination for session variables.

1. Create a class by inheriting SessionStore for supporting the save destination to be added.
2. Add the component definition of the created class to SessionManager.availableStores.