Attributes | Values |
---|
type
| |
Title
| |
content
| -
Preliminaries
The HTTP protocol does not define a session management
To make a HTTP session few options are possible:
To set a cookie, but this feature is not supported in all browsers.
To use the opaque value of the digest authentication, it is also not supported in all user-agents
The most common way for doing this is to pass an URL variable (http://host:port/path?variable=value) to keep the session id; this is usually named "URL-poisoning".
The Virtuoso HTTP session management consists of functions for session variables manipulation and an ability to define a pre- and post-processing function.
Also there is pre-defined table WS.WS.SESSION, which could be used in various applications to keep session data.
There are special functions to store/retrieve/restore a variables into the memory. These can be used to persist/restore the session variables.
For more details see: Session Management section in Virtuoso HTTP Server documentation.
Session Table
The Virtuoso server offers a built-in session table. Application developers can also use their own table.
CREATE TABLE WS.WS.SESSION (
S_ID varchar, -- session id
S_EXPIRE datetime, -- when it expires
S_VARS long varchar, -- serialized value of session variables
S_REQUEST_UNDER_RELOGIN long varchar, -- serialized value of request status upon re-login detected
S_REALM varchar, -- authentication realm
S_IS_DIGEST integer, -- flag for digest authentication
S_DOMAIN varchar, -- authentication domain
S_NONCE varchar, -- nonce value
S_OPAQUE varchar, -- opaque value
S_STALE varchar, -- stale value
S_QOP varchar, -- qop value
S_ALGORITHM varchar, -- algorithm name
S_NC integer, -- nonce count
primary key (S_REALM, S_ID))
Session Table handling
To set, clear, or preset the in-memory based session table, the following functions are available.
connection_set() - sets the connection variable.
connection_get() - get a connection variable state.
connection_vars() - get all connection variables.
connection_vars_set() - clear and set the session variables.
connection_is_dirty() - indicate state of the session variables (whether changed during the session).
Common Web application framework
The next examples demonstrates this three techniques for passing the session id to the VSPs
Every application have a startup page with links to login and register a new account
Once registered or logged in, the user will be redirected to the default page, that retrieves a session and variable increase it.
Also they have a authentication hook and post processing hook. These PL hooks are used to restore and save respectively the session variables.
The sessions are kept in the WS.WS.SESSION table. Note that not all columns are used in particular application. The full set of columns are used only in session with digest authentication example.
|
has container
| |
description
| - Introduction to HTTP session management
|
dcterms:created_at
| - Fri, 27 Dec 2019 14:12:54 GMT
|
content:encoded
| -
Preliminaries
The HTTP protocol does not define a session management
To make a HTTP session few options are possible:
To set a cookie, but this feature is not supported in all browsers.
To use the opaque value of the digest authentication, it is also not supported in all user-agents
The most common way for doing this is to pass an URL variable (http://host:port/path?variable=value) to keep the session id; this is usually named "URL-poisoning".
The Virtuoso HTTP session management consists of functions for session variables manipulation and an ability to define a pre- and post-processing function.
Also there is pre-defined table WS.WS.SESSION, which could be used in various applications to keep session data.
There are special functions to store/retrieve/restore a variables into the memory. These can be used to persist/restore the session variables.
For more details see: Session Management section in Virtuoso HTTP Server documentation.
Session Table
The Virtuoso server offers a built-in session table. Application developers can also use their own table.
CREATE TABLE WS.WS.SESSION (
S_ID varchar, -- session id
S_EXPIRE datetime, -- when it expires
S_VARS long varchar, -- serialized value of session variables
S_REQUEST_UNDER_RELOGIN long varchar, -- serialized value of request status upon re-login detected
S_REALM varchar, -- authentication realm
S_IS_DIGEST integer, -- flag for digest authentication
S_DOMAIN varchar, -- authentication domain
S_NONCE varchar, -- nonce value
S_OPAQUE varchar, -- opaque value
S_STALE varchar, -- stale value
S_QOP varchar, -- qop value
S_ALGORITHM varchar, -- algorithm name
S_NC integer, -- nonce count
primary key (S_REALM, S_ID))
Session Table handling
To set, clear, or preset the in-memory based session table, the following functions are available.
connection_set() - sets the connection variable.
connection_get() - get a connection variable state.
connection_vars() - get all connection variables.
connection_vars_set() - clear and set the session variables.
connection_is_dirty() - indicate state of the session variables (whether changed during the session).
Common Web application framework
The next examples demonstrates this three techniques for passing the session id to the VSPs
Every application have a startup page with links to login and register a new account
Once registered or logged in, the user will be redirected to the default page, that retrieves a session and variable increase it.
Also they have a authentication hook and post processing hook. These PL hooks are used to restore and save respectively the session variables.
The sessions are kept in the WS.WS.SESSION table. Note that not all columns are used in particular application. The full set of columns are used only in session with digest authentication example.
|
is container of
of | |