When using a website or web application combined with i-net Clear Reports it's recommended to only let the user log-in once. The solution for this scenario depends on your server infrastructure and selected authentication method.

In this configuration, i-net Clear Reports would be running in an application server that presents your web front-end or web application as well. It's recommended to set the authentication method to 'Internal web server' for that use case. This enables i-net Clear Reports to share the session and authentication with your web application.

If you require another authentication method or i-net Clear Reports runs in a separate process (e.g. IIS or Apache with PHP), make sure that i-net Clear Reports is accessed by the same host name as your front-end server. Furthermore, the credential store has to be the same for the web application and i-net Clear Reports. This is required to enable the client browser to automatically resend the authentication when switching between the web application and i-net Clear Reports. The user won't be notified about this re-login so the user experience is seamless.

In case you want to install i-net Clear Reports on a firewall-protected back-end server, a different setup for authentication has to be used. Since your web site or application is hosted on another (front-end) server, i-net Clear Reports has to contact this server to share the authentication. Make sure, this connection is not blocked by the firewall as well.

To set up this solution please:

• Setup a Proxy on the front end server. This can be done by using the ASPX proxy script located in the samples folder of the i-net Clear Reports SDK. If you're using another proxy, make sure to forward all cookies and/or the authentication header to the i-net Clear Reports server.
• Install a login script on the front-end server. See External Script section for details.
• Make sure the back-end server can contact the front-end server for the Login Script
• Configure i-net Clear Reports to the authentication method 'External web server' and set the 'Login URL' to the location of the Login Script on the front-end server

How it works in production:

It's important in this scenario, that request 1. and 2. pass all cookies (session ID) and header (authentication header). This allows the Login Script on the front-end server to identify a user by session cookie or by authentication.

In this scenario the web site/application server and the server hosting i-net Clear Reports are both connected to the same network or the internet. The user can directly access both servers. So in contrast to the front-end / back-end architecture, there is no proxy which can pass the authentication or session data from the web site/application server to the reporting server. So passing the session cookie has to be done by the web site running in the browser of the client/user. For that reason, a front-end / back-end solution is recommended in most cases.

To set up this solution please:

• Install a login script on the web site/application server, see External Script section for details.
• Modify your web site or application to present the i-net Clear Reports report or web interface in an IFRAME embedded in your web site/application
• Modify your web web site or application to pass the session cookie to this IFRAME so that the IFRAME uses this cookie when querying the reporting server
• Configure i-net Clear Reports to use the authentication method 'External web server' and set the 'login URL' to the location of the login script on the web site/application server.

How it works in production:

As you can see, the most critical point here is to pass the session from your web application to the reporting IFRAME. Most browsers will try to prevent you from re-using a cookie for another host. So it requires sophisticated JavaScript knowledge to implement such solution.

Alternatively you may pass the required session data as URL parameters to the IFRAME. But since i-net Clear Reports only passes Cookies and HTTP header fields to the Login Script, this would require to extend the reporting server with a plugin to convert the URL parameters to a cookie for authentication.