Class Wd_dialog.database_session_manager

class database_session_manager : ?private_key:string -> ?enable_checksum:bool -> allocate:(unit -> int) -> insert:(int -> string -> unit) -> update:(int -> string -> string -> string -> unit) -> lookup:(int -> string -> string * string) -> unit -> Wd_types.session_manager_type

The database session manager allows it to store the contents of sessions in databases. The database table should consist of rows with at least the four columns

id: The row identifier chosen by the database system. This is an integer
skey: The secure key consists of 32 hex digits, and is another identifier for the row that is chosen by WDialog
value: The value is a large BASE64-encoded string. The length depends on the session size
checksum: A checksum of value, again 32 hex digits

Note that sessions stored in databases behave differently with respect to the history function of the browser. It is not possible to "go back", or to select historic pages otherwise, and submit them again. This will be detected by the database_session_manager, and the exception Invalid_session_checksum will be raised. There is currently no way to turn this check off, nor to make the check more fine-grained. (Maybe an implementation with multiple versions of the same session is the way to go, I don't know yet.)

The database_session_manager does never delete sessions. It is recommended to remove unused sessions after a timeout period.

For a transaction-based DBMS, it is sufficient if the update function commits the current transaction.

private_key : The optional argument private_key can be used to inject randomness into the algorithm that computes the secure key. This makes the secure key unpredictable for the user, so nobody can "hijack" a session by guessing the secure key.

enable_checksum : If true (the default), the checksum of the web request is compared with the database checksum. This ensures that only responses of the latest dialog state can be processed. By setting this parameter to false, the checksum is ignored, and the user can also submit historical web forms. In general, this is a bad idea, and you will run into trouble, unless your application is can cope with that.

allocate : The function allocate must allocate a new id and return it.

insert : The function insert must insert a new row, containing only the id and the passed skey; the other two fields can be empty (empty string, or "null").

update : The function update takes the id, the skey, the value, and the checksum as arguments, and must update the row identified by id and skey. It is up to the implementation whether the id or the skey is the preferred lookup key; however it MUST be checked whether the found row has the demanded skey for security reasons; if this is not the case, the exception Session_not_found must be raised. This exception must be raised, too, if the row cannot be found at all. (If there are several matching rows, this is an implementation error!)

lookup : The function lookup gets the id and the skey as arguments, and must return the corresponding value and checksum as pair. Again, the exception Session_not_found must be raised if the row cannot be found, or the skey is wrong.