[Web] Disable login UI on autoprotocol domains

[DiscoNova]

Contribution Guidelines

• I've read the contribution guidelines and wholeheartedly agree them

What does this PR include?

Short Description

This PR adds a new configuration option to disable the login page on autodiscover and autoconfig domains (autodiscover.*, autoconfig.*). When enabled, these domains will return a 404 error instead of displaying the login interface for endpoints that haven't been defined elsewhere. This is useful because autodiscover/autoconfig domains are intended solely for automatic client configuration and should not expose the login interface.

For me, disabling the login-interface on the mentioned domains solved the problem I was facing with issue #6747 ... at least for now.

The implementation includes:

• Backend logic to store and retrieve the configuration setting via Redis
• Checkbox for enabling the option in the admin customization panel
• Login page check that returns 404 when accessing from autodiscover/autoconfig domains if the option is enabled
• Multi-language support (English, German, French, Dutch, Finnish, Swedish)

n.b. While I am a native Finnish/Swedish speaker myself with English as third language, and have studied French and German decades ago, my “Dutch” is actually learnt from Flemish speakers in Belgium, so some TLC review of the translations would be highly appreciated to avoid unintended idiosyncrasies and achieving technical consistency.

Affected Containers

• php-fpm-mailcow (PHP-FPM container)

Did you run tests?

I tested the feature manually, yes.

What did you tested?

Following components were tested:

• Admin panel UI: Verified the new checkbox appears correctly in the customization settings
• Configuration storage: Confirmed the setting is properly saved to and retrieved from Redis
• Login page behavior: Tested accessing the login page via autodiscover.* and autoconfig.* domains with the option both enabled and disabled
• Language translations: Verified all language strings display correctly in the UI

What were the final results? (Awaited, got)

Expected behavior:

• When the option is disabled (default): Login page displays normally on all domains including autodiscover/autoconfig
• When the option is enabled: Login page returns 404 error on autodiscover/autoconfig domains, but works normally on other domains

Actual results:
All tests passed and the feature works as expected:

• The checkbox appears in the admin panel under customization settings
• The setting persists correctly in Redis
• When enabled, autodiscover.example.com and autoconfig.example.com return HTTP 404 (for root endpoint access)
• When disabled or on regular (non-autoprotocol) domains, the login page displays normally
• All language translations render properly in the interface

[FreddleSpl0it]

Thank you for the PR.
I think there is no need to make it customizable. We should always return 404.
@patschi What do you think?

[DiscoNova]

I think there is no need to make it customizable. We should always return 404.

That would indeed simplify the implementation quite a bit; just leaving a few of the lines in index.php and dropping everything else that is maybe just adding unnecessary complexity ... the reason I made this optional is rather that since autodiscover/autoconfig aren't really standards as such, but rather proprietary protocols, I haven't found an actual "SHALL NOT"-guidelines forbidding using the domains for anything else for either of them - it is rather a community consensus that the domains should only be used for providing configuration data :-/

I also didn't want to make this into a breaking change which some users might - for some reason - currently be relying on. Those are always a pain to figure out when you upgrade a system and something you've grown to using (whether advisable or not) just stops working without a warning.

[DiscoNova]

Oh... furthermore... there are no guarantees that this change actually solves anything in regards to issue 6747 - disabling the DNS-entries for the domains remedied the situation for me for now ... but since Google's detection is an actual black box, saying anything definite is quite impossible.

[patschi]

Thank you for the PR. I think there is no need to make it customizable. We should always return 404. @patschi What do you think?

I like this change and I fully agree. No need for making it customizable.

I'd also suggest in replacing:

if (preg_match('/^(autodiscover|autoconfig)\./i', $server_name)) {

with something more simple like: (not tested!)

if (substr($server_name, 0, 12) === "autodiscover" || substr($server_name, 0, 10) === "autoconfig") {

Regex tends to be more costly performance-wise. And in the end, both should do the same?

[DiscoNova]

I could squeeze a bit more juice by using str_starts_with() since the project uses PHP 8.x (the native implementation is optimized for prefix-checking using memcmp without additional memory allocation the substring comparison necessitates) ... and you're absolutely correct that regex is indeed quite a bit overkill for such simple operation :D

Only question that remains is; do I just add another commit and keep the existing history, or should I rebase & rewrite history of this PR and force-push a new version? Or is there a third way things are preferred in this project?

[patschi]

str_starts_with sounds good indeed - great idea.

I'd say rebase & force-push - to keep the discussion in this PR too. Should do the trick.

[DiscoNova]

I've removed all the unnecessary changes that enabled making this feature optional (UI, localisations, backend storage) and left the essentials.

At one point I noticed diving deep into professional paranoia rabbithole trying to handle various imaginary edge cases that are very unlikely to ever be seen in real life and decided I was overthinking and should take a step back :D

The current version of the code makes one memory allocation for the lowercase hostname, which could be avoided at the cost of increased code complexity - but I think this implementation with a much more straight-forward approach is a good compromise between performance and future maintainability.

During my latest testing I did notice that the current server implementation actually responds to both protocol requests on both domains (i.e. you can request autoconfig-endpoints using autodiscovery-domain and vice versa) but that issue is way beyond the scope of this PR ... and probably of little consequence one way or the other.

[DiscoNova]

I understand this PR has only been open a few weeks (sometimes I've waited months for review etc. - often enough to completely forget what I was thinking about when submitting one:) but I wanted to ask if there is still something you folks would want changed / addressed in this pull request context? @FreddleSpl0it @patschi

[FreddleSpl0it]

@DiscoNova Looks good to me. I don’t have time for development right now, but I’ll likely get back to your PR in late December.

[milkmaker]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[DiscoNova]

While it looks like Google has come to its senses about marking the sites "unsafe"/"dangerous", I believe this PR would still make a good addition to the codebase - simply to avoid user ambiguity regarding the way the autoprotocol domains are meant to be used. But this is admittedly purely my personal opinion.