Make default page configurable, allow to disable public.pl and customer.pl

[bschmalhofer]

As of OTOBO 10.0.12 the default page of OTOBO is the agent interface. This is currently implemented in bin/cgi-bin/otobo.psgi. This feature can be overridden in a custom Nginx configuration. See https://otobo.de/en/forums/topic/default-page/ and https://doc.otobo.org/manual/installation/stable/en/content/installation-docker.html#custom-configuration-of-the-nginx-webproxy .

It would be nice if there were a more convenient way to do this.

[bschmalhofer]

Alternatively the default page could be set differently in otobo.psgi and in index.html. I'm not sure what the best approach is.

Here are example files that also changes /otobo/index.pl to /index.pl and so on

index.html.txt

otobo.psgi.txt
.

[bschmalhofer]

The newly implemented features are that the default page are configurable and that the public interface can be deactivated. Let's collect information about the current state and see whether anything needs to be changed. The new settings are Frontent::NotFoundRedirectPath and PublicFrontend::Active. The files index.html, robots.txt, and 404.html directly in '"$Home/var/httpd/htdocs/" are meant to be adaptable by customers and might be removed by customers.

See also #1584 and #1599.

• https://example.org/robots.txt gives $Home/var/httpd/htdocs/robots.txt when it exists
• https://example.org/robots.txt gives 403 Forbidden when $Home/var/httpd/htdocs/robots.txt does not exist
• https://example.org, https://example.org/, and https://example.org/index.html give $Home/var/httpd/htdocs/index.html when it exists, per default the page contains a redirect to /otobo/index.pl
• https://example.org, https://example.org/, and https://example.org/index.html give 403 Forbidden when $Home/var/httpd/htdocs/index.html does not exist
• Pathes below http://example.org/otobo-web are served as static files from $Home/var/httpd/htdocs/ when they are available, either from disk or from the S3 backend
• Pathes below http://example.org/otobo-web that are not available are served with status code 404 and content from 404.html when it the file exists, status code 500 and 'Internal server error' when the file does not exist.
• Everything else outside /otobo/ behaves like not found files in /otobo-web
• The recognised pathes in http://example.org/otobo/ are: customer.pl, index.pl, installer.pl, migration.pl, nph-genericinterface.pl
• http://example.org/otobo/public.pl is recognised only when public.pl is activated in the SysConfig
• everything else in /otobo redirects to Frontent::NotFoundRedirectPath

[bschmalhofer]

The changes seem to work, but it would be good to have a review whether the current behavior is sane enough for a release,

[svenoe]

After a short discussion we agreed on the following changes:

• index.html per default redirects to /otobo (where then the SysConfig will determine where to go further (already implemented))
• public.pl can also be chosen as a redirect option from /otobo (not actually a change in the current implementation, as it is a text field, not a selection; would be nice to change, but I am not sure whether the selection - I will write an example below - can be combined with <OTOBO_CONFIG_ScriptAlias>)
• customer.pl can also be disabled via SysConfig (like public.pl)
• additionally it would be nice to have the choice of default redirect in the installer. But only if it is a selection, and this only if we can change the ValueType of the SysConfig to "Select" (and still use the OTOBO_CONFIG tag)

An example for a selection is:

        <Value>
            <Item ValueType="Select" SelectedID="100">
                <Item ValueType="Option" Value="100" Translatable="1">100 (Expert)</Item>
                <Item ValueType="Option" Value="200" Translatable="1">200 (Advanced)</Item>
                <Item ValueType="Option" Value="300" Translatable="1">300 (Beginner)</Item>
            </Item>
        </Value>

[bschmalhofer]

After more thinking, the selection of the default page can be between index.pl, customer.pl and public.pl. The redirect can be relative to otobo/ or to whatever otobo/ has been aliased to.

[bschmalhofer]

Also:

• when the selected default interface is deactivated, then fall back to index.pl in order to avoid an useless extra redirect

[bschmalhofer]

The current state of affairs is merged. The enhancement of installer.pl has been moved to #1633 as there might more settings that should be included.

[nm583]

* [x]  index.html per default redirects to /otobo (where then the SysConfig will determine where to go further (already implemented))

This was not the case in "my" index.html after an OTRS migration.
I did a fresh install of OTOBO 10.1.6 (with docker) and completed the OTRS migration from 6.0.30. No errors during migration.
After migration I set Frontend::DefaultInterface to Customer Interface.

Behaviour:
myIP redirected to myIP/otobo/index.pl
myIP/otobo redirected to myIP/otobo/customer.pl

I checked index.html and it said:

<head>
    <meta http-equiv="Content-type" content="text/html;charset=UTF-8" />
    <meta http-equiv="refresh" content="0; URL=/otobo/index.pl" />
    <title>OTOBO Redirect</title>
</head>

Removing the "/index.pl" led to the correct expected redirections.

As also the Copyright of Rother OSS GmbH was missing at the bottom (only had the OTRS part), I think it could be related to the migration process.

[bschmalhofer]

Hi @nm583 ,
this seems to an artefact of the migration from OTRS. An existing file var/httpd/htdocs/index.html is copied from OTRS to OTOBO. This makes sense, as var/httpd/htdocs/index.html might have been customized in OTRS. The original OTOBO file is still available in /opt/otobo_install/otobo_next/var/httpd/htdocs/index.html . Apparently the migration did some rewriting, changing "otrs/index.html" to "otobo/index.html" and "OTRS Redirect" to "OTOBO Redirect".

I'm not sure whether the migration should generally change the "/otrs/index.html" to "/otobo". I'll file it as an separate issue.

[bschmalhofer]

Hi @nm583,
after a brief internal discussion we decided to keep the migration as it is now. It's hard to find a good general rule for that, as the next user might be wondering why the migration changed index.html in an unexpected way.