Technical

Settings: Technical
Settings: Technical

Technical

Maximum use in MB
The option ‘Maximum memory use in Mb’ checks how much memory is available every time an instance is created. When usage exceeds the given Mb in this setting, the instance will not be created, and the user will get a warning message.
Maximum file upload in KB
Limits the size of the Get Request to the server. When a request exceeds the given Kb in this setting, the request is not processed, and the user will get a warning message.
Unique Server number
This can be used when multiple servers are used on a single computer and have to be distinguished from one another. Used in combined caching databases or clusters
Use BB identity server for login
The list is extracted from the list in datasources. Select a BB Identity server to make sure that a user is redirected to the BB Identity server if he or she tries to log on to the server. (See [Berkeley Bridge Identity Server](/the webserver/bbiserver) for more information)
Warning slow responsetime (sec)
You can let the server give an (internal) error message each time the response time was longer than the given number of seconds. This way, you can be warned if the server is getting to busy, or some actions (like a slow backend connection to a database) is getting too slow.
Accept only from localhost
When the server is behind a proxy server, or if only used locally, this checkbox makes sure only local requests get processed.
Use ticketing
If checked, the server will set the ticketing system in work (ticketing means you can set a user to access a model only a number of times)
Part of cluster:
If checked, the server will use Windows-locking and more checks of the files like login.xml. This way, servers can work together in a cluster.

Logging

User IP Log
If checked it is registered which models are opened by which user. In the log you will see lines like the following appear: 2013-12-11 14:49:56.089;127.0.0.1;”demo”;”demo”;”backslash_n_in_complex”
Anonymous IP Log
If checked the IP’s will be replaced by ..., making the log not traceable anymore
Detail log
If checked, the log will show each and any action performed by the Webserver. This is a useful tool if problems arise and the log files can be analyzed by the Berkeley Bridge service desk. It does take up lots of resources, so turn it off in faultless production use.
Log to user (admin) allowed
If checked, an administrator can see the produced log of the current session. This checkbox has to be checked as well if you want the IP log of the server.
Log sending mail
If checked the server will log all mails send. Used for adminstration purposes. The messages are saved in the file maillog.log. A line will consist of atime, email adres and subject. For example 15-02-2018 14:44:19.196 | Message sent to somebody@zonnet.nl (Your personalized employment agreement)
Expiration old log files (days)
Each time a new log file is created, the server can check if there are log files older than the given number of days. This way, your hard disk will not reach its limit.

Sessions

Add time created and user name to case file name
‘Add time created and user name to case file name’ adds user and creation date of the session to the name of the case file on the server (model name and sessionid are included by default).
Allow admin overview of all sessions
When this is ticked, someone logged in as administrator has read and write access to all sessions of all users. If the web environment includes a case overview, the administrator will see the sessions of all users listed here.
Escape interface output (unsafe if not checked)
When this option is checked, it is possible to put HTML-code inside certain labels. Since labels may reference user input, code-insertion may be possible, which is unsafe. Does not affect JSON output
Parameter “newname” can open case"
If checked, an deeplink to a model can use the parameter newname to give the case a name.
Show anonymous models in menu
This option will show all the anonymously published models to the user.
Use all start-up parameters (not safe!)
If you check the option ‘use all startup parameters’ this information will be treated as normal. This is to say it will be available in the model and stored in the case. For obvious reasons you should not use this option unless it is absolutely necessary.
Use persistent jumplist
Our take on ‘Save the future’: when a user jumps back, jumplist items ‘further down the road’ will be left in the jumplist to jump forward to.
Use reference check text production
Enable numbering in HTML and RTF text productions. See the help documentation for the Berkeley Document Designer if you want to know how to use this. If you do not have numbering in your templates, turn this option off: it will save time when generating texts.
Use session parameters
Parameters can be passed to the Runner/Webserver that can be used in the model. In case of the Berkeley Webserver the username and password have to be passed to provide access to the model. These parameters can be retrieved in the model by the function ‘getparambyname’. The parameters are stored in the case (session). Because saving sensitive data such as credentials always implies a security risk, the following parameters are excluded from saving: ‘username’, ‘password’, ‘sessionid’, ‘caseindex’, ‘modelname’, ‘dbname’, ‘uniqueid’, ‘fmt’ and ‘templateindex’. This information is not stored, nor is it available in the model.
Use cookies
Normally the session-information is controlled by the uniqueid in the communication. If this checkbox is checked, cookies are used to authenticate the user. This function has his setbacks in SSO etc. so this can only be used in some cases.
Share cases
If checked, the model is allowed to transfer the ownership of a case.