Wrong link to a form with responses

[stefan-franz]

The right link to the form with the results is e.g.
https://nx4XXXXX9.your-storageshare.de/apps/forms/Q82JPnBYDCm8FktW/results

But the link in the e-Mail is:
https://nx4XXXXX9.your-storageshare.de/index.php/apps/forms/Q82JPnBYDCm8FktW/results

to the "index.php/" is the reason for the wrong link. How can this fixed?

I use the nextcloud of hetzner.com - V27.1.2 - and Forms 3.3.1

[Chartman123]

I can confirm this, the link inside Nextcloud is correct, the link in the mail always contains index.php. However, I'm not sure, if this a bug of Forms or if this has to be fixed in the Activity app or the Server core.

@jotoeri @susnux Can you tell me more about how the notifications and the link handling works? I only found this line here:

forms/lib/Activity/Provider.php

Line 252 in 28ed367

$formLink = $this->urlGenerator->linkToRouteAbsolute('forms.page.index');

So this makes me wonder how there could be two different links in the web notification and in the mail...

Edit:
Ok, the UrlGenerator always adds the index.php to the path. So probably the web notifications checks the config/htaccess settings and removes that part whereas the mail notifcation doesn't modify the link after the creation. So can we affect that?

[susnux]

This is a configuration issue, the index.php is always added - except when the front controller was setup correctly.

If you use Apache the Nextcloud setup will automatically add this to the .htaccess:

<IfModule mod_env.c>
	SetEnv front_controller_active true
	<IfModule mod_dir.c>
		DirectorySlash off
	</IfModule>
</IfModule>

This will set the front_controller_active variable that then disables the index.php/ part of the absolute URL the URLGenerator generates.

If you do not use Apache but rewrite your URL to not include the index.php then you can set this in your Nextcloud config:

$config = [
    // ...
    'htaccess.IgnoreFrontController' => true,
    // ...
];

See also: https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/config_sample_php_parameters.html#htaccess-ignorefrontcontroller

[Chartman123]

@susnux I have set the correct part in .htaccess and also default in config.php and yet I can't access the form from the link inside an email because of the index.php part. As soon as I remove it from the link I get to the linked form. So I think that there must be something that doesn't work correctly.

[susnux]

Are you behind a reverse proxy?

[Chartman123]

Yes, community docker behind a traefik reverse proxy...

[susnux]

Could you please check this on your instance? Just run it in the browser console:

_oc_config.modRewriteWorking

what is the state? true or false?

[Chartman123]

I get true

[susnux]

I am also on community docker currently but the only config I set there is APACHE_DISABLE_REWRITE_IP=1.
I am behind a NGinx proxy and for me everything works as expected.

[susnux]

So I am out of ideas, somehow your system still adds the index.php even if mod rewrite works correctly.

Could you maybe apply this, set to debug log level and report the log entry? Maybe that shows which part exactly is doing wrong stuff:

index e7e2a9f0e49..55755afe528 100644
--- a/lib/private/Route/Router.php
+++ b/lib/private/Route/Router.php
@@ -98,6 +98,15 @@ class Router implements IRouter {
                }
                $host = $request->getServerHost();
                $schema = $request->getServerProtocol();
+
+               $logger->debug('Constructing router', [
+                       'root' => \OC::$WEBROOT,
+                       'base' => $baseUrl,
+                       'ignore' => $config->getSystemValue('htaccess.IgnoreFrontController', false),
+                       'env' => getenv('front_controller_active'),
+                       'host' => $host,
+               ]);
+
                $this->context = new RequestContext($baseUrl, $method, $host, $schema);
                // TODO cache
                $this->root = $this->getCollection('root');

[susnux]

I could reproduce this, it seems this is a Core or Activity issue, ref: nextcloud/activity#1617

As a workaround you could add front_controller_active=true to your ENV when executing cron.php