sessionkeys

sessionkeys are very important for the frontend and the backend.

In the backend sessionkeys control login-status and various settings (like searchstring, actual page etc. for visited tables)

In the frontend they control login-status as well, but even not-logged-in-users get a sessionkey (to allow them using the warenkorb in future extensions ...)

 cdate  | timestamp with time zone | default ('now'::text)::timestamp(6) with time zone
 udate  | timestamp with time zone | default ('now'::text)::timestamp(6) with time zone
 s_key  | character varying(50)    | not null
 c_key  | character varying(30)    | 
 login  | character varying(30)    | 
 id     | text                     | 
 values | text                     | 
 uid    | integer                  | 
 gid    | character varying(100)   | 
 tb     | character varying(30)    | not null

Indexes:
    "session_pkey" PRIMARY KEY, btree (s_key, tb)
    "idx_session_ckey" btree (c_key)
    "idx_session_skey" btree (s_key)

c_key is for callsession, that are not used in this project.

for each table a new entry in this table is created. s_key and tb are the primary key. as soon as a valid s_key is found the user is accepted. Only entries where the login-field is set are queried.

each visitor - no matter if logged in or not - gets a sessionkey. The sessionkey is stored in the session-table with tb=’frontend’. if no user is logged in, the login-fields stays NULL and is ignored by the BACKEND.

a backenduser is logged in. So s_key and login-field are set. The sessionkey is therefore accepted by the frontend and the user is logged on.

if the visitor is not logged in, the login-field is empty and therefore the sessionkey is ignored by the backend and the user needs to login.
if the visitor is logged in the login-field is set and the backend accepts the login.