<divclass="noteclassic">When a user access a Handler without a cookie, he is redirected on portal, and the target <abbrtitle="Uniform Resource Locator">URL</abbr> is encoded in redirection <abbrtitle="Uniform Resource Locator">URL</abbr> (to redirect user after authentication process).
To encode the redirection <abbrtitle="Uniform Resource Locator">URL</abbr>, the handler will use some Apache environment variables and also configuration settings:
</p>
<ul>
<liclass="level1"><divclass="li"><strong>HTTPS</strong>: use https as protocol</div>
</li>
<liclass="level1"><divclass="li"><strong>Port</strong>: port of the application (by default, 80 for http, 443 for https)</div>
</li>
</ul>
<p>
These parameters can be configured in Manager, in <code>General Parameters</code>><code>Advanced parameters</code>><code>Handler redirections</code>.
<divclass="notetip">These settings can be overridden per virtual host, see <ahref="configvhost.html"class="wikilink1"title="documentation:2.0:configvhost">virtual host management</a>.
Handler use the default Apache error code for the following cases:
</p>
<ul>
<liclass="level1"><divclass="li"> User has no access authorization: FORBIDDEN (403)</div>
</li>
<liclass="level1"><divclass="li"> An error occurs on server side: SERVER_ERROR (500)</div>
</li>
<liclass="level1"><divclass="li"> The application is in maintenance: HTTP_SERVICE_UNAVAILABLE (503)</div>
</li>
</ul>
<p>
These errors can be catch trough Apache <code>ErrorDocument</code> directive or Nginx <code>error_page</code> directive, to redirect user on a specific page:
</p>
<preclass="code file apache"><spanclass="co1"># Apache: Common error page and security parameters</span>
It is also possible to redirect the user without using <code>ErrorDocument</code>: the Handler will not returnV 403, 500, 503 code, but code 302 (REDIRECT).
</p>
<p>
The user will be redirected on portal <abbrtitle="Uniform Resource Locator">URL</abbr> with error in the <code>lmError</code><abbrtitle="Uniform Resource Locator">URL</abbr> parameter.
</p>
<p>
These parameters can be configured in Manager, in <code>General Parameters</code>><code>Advanced parameters</code>><code>Handler redirections</code>:
</p>
<ul>
<liclass="level1"><divclass="li"><strong>Redirect on forbidden</strong>: use 302 instead 403</div>
</li>
<liclass="level1"><divclass="li"><strong>Redirect on error</strong>: use 302 instead 500 or 503</div>
<divclass="noteclassic">If a user is redirected from handler to portal for authentication and once he is authenticated, portal redirects him to the redirection <abbrtitle="Uniform Resource Locator">URL</abbr>.
</div><ul>
<liclass="level1"><divclass="li"><strong>Redirection message</strong>: The redirection from portal can be done either with code 303 (See Other), or with a JavaScript redirection. Often the redirection takes some time because it is user's first access to the protected app, so a new app session has to be created : JavaScript redirection improves user experience by informing that authentication is performed, and by preventing from clicking again on the button because it is too slow.</div>
</li>
<liclass="level1"><divclass="li"><strong>Keep redirections for Ajax</strong>: By default, when an Ajax request is done on the portal for an unauthenticated user (after a redirection done by the handler), a 401 code will be sentwith a <code>WWW-Authenticate</code> header containing “<abbrtitle="Single Sign On">SSO</abbr><portal-<abbrtitle="Uniform Resource Locator">URL</abbr>>”. Set this option to 1 to keep the old behavior (return of <abbrtitle="HyperText Markup Language">HTML</abbr> code).</div>
<liclass="level1"><divclass="li"><strong>Skip re-auth confirmation</strong>: by default, when re-authentication is needed, a confirmation screen is displayed to let user accept the re-authentication. If you enable this option, user will be directly redirected to login page.</div>