this involves two areas:

• search only retrieves accessible documents
• get_data only retrieves accessible documents

each module/database that should have this feature gets an extra field. This field can be null for a certain entry in the module to allow access to this entry for everyone or it can contain the list of groups that can access this document.

based on this data the buid-search-index-routing builds a new datastructure that makes this information fast accessible:

$blacklist->{activ}->{MODULE}=1  ... this module can have protected documents
$blacklist->{protected}->{MODULE}->{ID}=1 ... this document is protected
$blacklist->{accessible}->{MODULE}->{ID}->{GROUP}=1 this group has access

MODULE and ID are the compressed values as described in search-how and in the source of build_search.
The blacklist allows us to evaluate protected documents extremely fast as long as there are not too many documents protected !!!

During the SPLIT-process in goldfisch::search2::search() we can query each result very efficiently if a matched document is in the blacklist. If yes we need to perform a second step where we check if the document is accessible for the current user. This involves a query for each group the current user is member of, which is more timeexpensive. If this is too expensive we would need to create an additional structure

$blacklist->{accessible}->{MODULE}->{ID}->{USER}=1

get_data needs to query $blacklist if any document could be protected. if yes -> each document needs to be checked and if protected be checked against the current user.

1. adapt a backend-table
2. adapt build_index to create the needed structures
3. adapt search-engine - we need a pseudo-user until the real login is finished

• login needs unique identification of users
• cookies - later we might use session-keys in case cookies are not supported
• each user is identified. even if not logged in. this will allow us to create “warenkorb” later.
• each user/sessionkey will be stored to a database. one field in this database will be “username”, “authorized”,”groups”

1. each new user gets a cookie set. the cookie contains a unique sessionkey which is saved to the database.
2. on every request the cookie is read and the content of the database is read and provided via a system-variable
3. if a user logs on successfully, then mainly the database is updated with “username”, “authenticated”,”groups”

• cookies should be compatible with backend????
• sessions are protected by ip-adress and useragent?
• how long are session valid? lifetime? one week? only one session?

• if a sessionkey is read it needs to check if the user still exists !! on lifetime-sessions we can delete a user and the session-keys stays valid !!

• a login/pass-form on every page
• a link to the backend-login
• if a user logs in, instead of the login/pass-form the message “thnx for logging in” appears
• if a user is logged in then username is shown instead of the login/pass-form and a logout-button !!

• login is possible on each page. so the url of the form-action needs to be the url of the actual page + a LOGIN-part that is processed by the engine. The login-process is done in the heart of the engine and then the usual page is shown.
• same for logout !!

• the engine will provide the following information in system-variables:
  1. username (empty if not logged in)
  2. login-action if the current action was a login or logout
  • based on this variables the template should be very easy to meet the demands of the userinterface

• a content needs to be available in different languages

1. as in “textarchiv” we have a text-id to connect two or more entries that are the same content in different language !! each content is nevertheless independet of the selected navigation-language and can be found via search !!
2. depending on the selected language the shown content is different. This is useful for navigation in textarchiv, where the navigation is actually content. This is not useful for real content, cause then english content can only be seen in english navigation !! This means as well, that databases with this feature MUST NOT be searchable. Otherwise one would find a english text, but if one clicks on it in german navigation the german text ist shown !!

This new feature will implement multilangual content that depends on the select language !!

• the supported table will get additional content-fields for each supported language !!
• in backend this is solved by simply showing the fields for small fields or in case of large text (unlikely) a special solution is necessary.
• get_data will get a sister get_data_lang where the retrieved data depends on the language !!