Cookieless sessions are available in versions 2018.1 and above.
When a user enters Exago BI, the application creates a session in order to preserve the user's working state and environment while they engage in application tasks. The session information is stored on the web application server or state server (depending on the network configuration). Whenever requests are made, the user's browser sends a unique, randomly generated ID to the web server in order to authenticate the user and preserve the connection between user and session.
To enable cookieless sessions, locate the following line in the WebApp\web.config file and set the
cookieless attribute to true:
<sessionState mode="InProc" cookieless="true" timeout="20" />
Cookieless sessions work to preserve state by appending the session ID to the URL string itself, which is used to connect to the web server. For example, a standard application URL generated by the server API after creating a session looks similar to the following:
With cookieless sessions enabled, the session ID is added to the URL, for example:
This has no direct implications for the embedding process into the host application.
When the web application server is exposed to the internet or any insecure public network or intranet, you need to enable secured authentication to prevent unauthorized access.
Because the session ID is passed as a part of the URL, it can be used by malicious third parties to send unauthorized requests to the web server. Secured authentication causes the web server to require a secondary security token in order to authenticate the session. This does not require any additional effort on the part of the end-user.
To enable secured authentication, edit the WebApp\appSettings.config file and add the following line:
<add key="useSecurityToken" value="True" />
The server API generates a security token with the session and embeds it into the page markup. It is sent with every client request as a part of the payload. When using a secured connection, the payload is encrypted, thus making it nearly impossible for a malicious party to derive the token.
Caution: Unsecured connections will compromise any security intended by the use of secured authentication. If the payload is unencrypted, the token can be easily intercepted by a third party. The web server must enforce HTTPS in order for secured authentication to function properly.
Cross-Origin Resource Sharing
If the Exago BI application is being accessed over a network, the Exago web server must be configured to allow cross-origin requests to the client host application.
By default, a web application making a request for content that originates from a remote server sends a cross-origin HTTP request. For security reasons, browsers restrict these types of requests when they originate from scripts.
To permit content to be accessed by whitelisted resources, you can configure the Exago web server to send a Access-Control-Allow-Origin header. For example:
In IIS, this is either set in the HTTP Response Headers or added manually to the
In Apache, following line is added to all relevant
Header set Access-Control-Allow-Origin "hostapp.server.com"
See Cross-Origin Resource Sharing (CORS) - HTTP | MDN (Mozilla) for more information.