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?