Wrong URL (non-Pretty) in digest mail

[susnux]

Steps to reproduce

1. Configure Nextcloud to not use index.php (mod rewrite)
2. Configure cron to run using cron jobs (not web!)
3. Trigger any activity containing an link (e.g. calendar event modified or form shared)
4. Wait for digest mail

Expected behaviour

Absolute URL used in email is using correct server address without the index.php.

Actual behaviour

Message contains the index.php.

Other

I checked everything - the URL generate correctly generates the link when used from the webui (e.g. in the notifications app).
But not when sending the digest mail.

I guess the problem is that a background job is sending it, the background job is called by the cron.php which is not using a real request thus the environment for removing the index.php (front_controller_active) is not set.
So when calling the Activity Provider within that context the generated URL will always include the index.php which - depending on the server configuration can be invalid and lead to 404 error.

[susnux]

PS: I am not sure if this is not a server core issue, at least I could not find any information in the docs saying you can not rely on URL Generator when running from background jobs.

[jancborchardt]

@sorbaugh @nickvergessen could you check whether this is an issue in Activity or Server? It causes for example this issue in Forms:
nextcloud/forms#2598

[susnux]

I think this could be a deeper problem in the URL generator, maybe @come-nc knows if I am right here:
For normal usage we have either the mod_env set value for frontcontroller active or we manually set htaccess.IgnoreFrontController in the config for non-apache setups.

If you are on an Apache server with mod_env you would not need to setup that config value.
But now when running within the cron context we do not have any information about the frontcontroller, so we always need to setup htaccess.IgnoreFrontController similar to cli.override.url.

[nickvergessen]

I think this could be a deeper problem in the URL generator

Or even the symfony router below. Becomes a bit visible by the handling in linkToOCSRouteAbsolute‎()
https://github.com/nextcloud/server/blob/master/lib/private/URLGenerator.php#L96-L108

[nickvergessen]

But all that being said, URLs with index.php should still work. At least they work for any other app,
e.g. https://cloud.nextcloud.com/call/c7... and https://cloud.nextcloud.com/index.php/call/c7... both would open the same talk conversation.
So there is a fair chance that forms is miss reading the initial route URL when mounting it's Vue?

[nickvergessen]

Not sure if that is due to the desktop client with talk, but https://github.com/nextcloud/spreed/blob/main/src/router/router.js#L20-L33 looks fairly more complicated then https://github.com/nextcloud/forms/blob/main/src/router.js#L21

PS Since it's only applied in !IS_DESKTOP I think that is exactly what the forms app would need to do?

[susnux]

Maybe that could fix Jan's problem - I will check - but it will not fix the problem of the original issue reported.
That the email contains links with index.php inside - which is an URL generator issue of server it seems.

Because there we expect pretty URL also to accept the full URL including index.php, but that is not necessary the case.
So the real bug to fix would be for the URL generator to also generate pretty URLs from the CLI (background job).

I think its not possible similar to why we need the cli.overwrite.url - maybe just document that for pretty URLs you also need to always manually set htaccess.IgnoreFrontController in the configuration or maybe also for consistency add a new config like cli.overwrite.prettyurl.

[susnux]

Maybe that could fix Jan's problem - I will check - but it will not fix the problem of the original issue reported.

It does, but here again this is a workaround for a server issue.
As noted above from my point of view the invalid URL should have never been generated.

But even then there is another issue here, as the server sets following JS config window._oc_config.modRewriteWorking == true but its not it is containing the index.php so it should report false or even do a 301 for redirect to the route without index.php.

Another problem here is that many other apps also do it like forms, so I wonder why there are less bug reports - maybe background job generated URLs are not that common 😅