Block/skip invalid user agents

Problem/Motivation

Currently we observe that empty or invalid user agents are passed. Thus, the login link is always invalidated and login is no longer possible.

After a detailed analysis, it was determined that Microsoft Office users in particular have this problem. It seems that Microsoft tries to disguise its own crawlers in order to scan the links in advance. Unfortunately, this is completely counterproductive and should be stopped.

Attached is a current example from the logs, the Microsoft crawler with an empty/invalid user agent calls the onte time login link, when calling the link itself. This is invalidated and the user's request, which is processed a second later, does not get access.

127.0.0.1 - - [31/Oct/2023:10:18:58 +0100] "HEAD /user/reset/USER-ID/TIMESTAMP/HASH HTTP/1.1" 302 0 "-" "-"
127.0.0.1 - - [31/Oct/2023:10:18:58 +0100] "HEAD /reset?check_logged_in=1 HTTP/1.1" 302 0 "-" "-"
127.0.0.1 - - [31/Oct/2023:10:18:58 +0100] "HEAD /user/login HTTP/1.1" 200 0 "-" "-"

127.0.0.1 - - [31/Oct/2023:10:18:58 +0100] "GET /user/reset/USER-ID/TIMESTAMP/HASH HTTP/2.0" 302 346 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36"
127.0.0.1 - - [31/Oct/2023:10:18:59 +0100] "GET /user HTTP/2.0" 302 382 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36"
127.0.0.1 - - [31/Oct/2023:10:18:59 +0100] "GET /user/login HTTP/2.0" 200 16896 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/118.0.0.0 Safari/537.36"

Steps to reproduce

Proposed resolution

It is checked if it is a valid user agent before the query is even processed.

Remaining tasks

User interface changes

API changes

Data model changes