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.
backend -> frontend
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.
frontend -> backend
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.