System Configuration Security Tab

Description

The table below identifies the settings found on the Security tab in the System Configuration package. Changing these settings arbitrarily can have important ramifications on the running of your application, so we recommend that you do not make changes before you discuss them with LogicNets Support.

Parameters

Field	Options	Details
Logicnet visibility (default: internal)	- public - internal - private	This determines the default visibility of all new logicnets created in the system, and you can make any specific logicnet more or less visible by going to the logicnet Details tab. public: This allows direct external access by the browser (e.g. via openlnet call). internal: This allows access by any logicnet call node. private: This allows access only from call nodes in the same project, package, or framework.
Web-security level (default: safe)	- default (safe) - strict - safe - develop - none	The web-security level dictates the treatment of web functions, print functions, and logging, specified in the table below: In LogicNets releases prior to 7.4 the default web-security level is "develop".
Entropy (default 16)	Integer	This is the number of random bytes the system should use for the session ID and session file name.  When the entropy is low the session id and session pin id are less unique, and they are easier to compromise. Entropy that is too high slows down the system, since generating such ids is time consuming.
Enforce HTTPS (default: Yes)	- Default - No - Yes	LogicNets recommends that you enforce HTTPS. If enabled, the system redirects an incoming HTTP request to an HTTPS request. You should only disable this if you specifically require HTTP.
Disable session pinning (default: Yes)	- Default - No - Yes	To avoid sessions being stolen or taken over, the LogicNets runtime engine uses session pinning. Note: Session pinning only works with HTTPS.
Security cookies 'samesite' attribute (default: Lax)	- Default - None - Lax	LogicNets uses cookies to work properly. With the samesite cookie setting, a web server tells the browser when a cookie will be sent to the server and when it will not be sent. Until 2020, most browsers used 'lax' as default when no samesite attribute was set. Since 2020, this has been changed to 'strict'. Most LogicNets applications will work properly with the default ('lax'). If an application is embedded in an iframe that runs in a different domain, set the option to 'None'. For more general information, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie/SameSite.
X-Frame-Options (default: Same origin)	- Default - Same origin - Deny - Allow all	Use the X-Frame-Options HTTP response header to indicate whether or not a browser should be allowed to render a page/application from this instance in a <frame>, <iframe>, <embed> or <object>. This allows you to avoid click hijacking attacks by ensuring that your content is not embedded into other sites. For more information, see the following: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options https://developer.mozilla.org/en-US/docs/Web/Security/Types_of_attacks#click-jacking
Access-Control-Allow-Origin		The Access-Control-Allow-Origin header is included in the response from one website to a request originating from another website, and it identifies the permitted origin of the request. A web browser compares the Access-Control-Allow-Origin with the requesting website's origin and permits access to the response if they match. This tells the browser whether it is allowed to access resources in your applications, such JS, web APIs, and images, from other websites. For more information, see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin Defaults to: *
Access-Control-Allow-Headers		The Access-Control-Allow-Headers response header is used in response to a preflight request, which includes the Access-Control-Request-Headers to indicate which HTTP headers can be used during the actual request. This information can be used by the client or browser to know which headers can be consumed safely. Passing data via other headers may result in exposing to the server sensitive information that is not processed correctly or safely. This could be inadvertently logged or stored in an insecure location. For more information see: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers https://developer.mozilla.org/en-US/docs/Glossary/Preflight_request Defaults to: content-type, authorization, x-requested-with, ln-auc-contract-number, ln-auc-contract-consumer
Content Security Policy (CSP)		CSP helps to avoid malicious code or content being inserted in the LogicNets application. See also https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP. Defaults to: default-src 'self'; script-src 'self' www.googletagmanager.com www.google-analytics.com www.googleadservices.com http://localhost:41666 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' 'unsafe-inline' secure.gravatar.com api.atlassian.com i2.wp.com; connect-src 'self' www.googletagmanager.com http://localhost:41666 ws://localhost:41666
Permission-Policy		More information coming soon.
Non-approved redirect-uris mode (default: log)	- Default - Block - Log only	This mode specifies how the system handles URIs that are not approved/whitelisted. "log only": When you use a URL that is not whitelisted and the user follows the redirect, the system logs the error "Illegal redirect uri specified" but continues with the redirect. "block" (recommended): When you use an external URL that is not approved and the user follows the redirect, the system logs an error and shows the user an error message, such as "the specified redirect_uri is not whitelisted". The system will not follow the redirect. Future releases will likely set block as the default setting.
Approved redirect-uris	Redirect URIDescriptionCreated by	This mode specifies that all URIs listed here are whitelisted, and the Redirect URL column can contain the following: A full URL: e.g. https://sub.mydomain.com/folder/page.html, only this page is whitelisted. A part of an URL: e.g. https://sub.mydomain.com/folder, all pages with this folders and its sub-folders are whitelisted. Or only a host name: e.g. https://sub.mydomain.com, all pages with this hostname are whitelisted; if the schema (in this case "https://") is omitted a https schema is assumed. You can use wild cards in the host name; for example, to whitelist all sub-domains you can use the following URI: https://*.mydomain.com. For security reasons it is better to use full URLs as much as possible. The description and created by fields are not mandatory and you can use them for your own information.
Whitelisted directories	One directory per input box	These fields allow you to list the folder and files that parts in your application can access on your server. For additional information, see Whitelisting Directories.
Use OS Certificate Store (default: 1)	- Default - Yes (1) - No (0)	Outbound web API calls can use HTTPS. HTTPS itself encrypts the connection, and it can also verify the hostname. To do this properly the remote certificate needs to be checked against a root CA certificate. These root certificates can be installed manually, but you can also use the Windows Certificate store. For more information, see Certificate Verification.
Outbound Webservice Security
Non-approved Outbound Webservice mode (default: block) v8.1+	- Default - Block - Log only	With LogicNets v8.1+, by default, this mode blocks or logs all outbound webservice calls except those whitelisted in the next configuration option. For more information about web services review the call webservice article, which includes a link to a demo project.
Approved Outbound Webservice-URIs v8.1+		Enter URIs here that are approved for outbound webservice calls. Check the box to also allow passing of user profile access tokens. You can enter a description for each URL as a reminder of use/requirement, and the system logs all entries by user for audit purposes.