I´m wondering why routes in Fortify which don´t require a user to be logged in has the auth middleware attached to it.
E.g. the Route to verify an E-Mail
Route::get(RoutePath::for('verification.verify', '/email/verify/{id}/{hash}'), [VerifyEmailController::class, '__invoke'])
->middleware([config('fortify.auth_middleware', 'auth') . ':' . config('fortify.guard'), 'signed', 'throttle:' . $verificationLimiter])
->name('verification.verify');
This leads to an "unauthenticated" response if no session cookie is set which doesn´t make much sense to me when a user has to verify his e-mail address via a link that has sent to him by email.
The reason for having the auth middleware in the email verification route might be to handle cases where users are trying to verify their email while being logged in. For instance, after registering, a user might stay logged in but not immediately verify their email. When they eventually click the verification link, the application can check if the currently logged-in user matches the ID in the verification link, which is a common approach to ensure that the correct user is verifying their email.
However, you are correct that this setup can cause issues if a logged-out user attempts to verify their email and hits the auth middleware, resulting in an "unauthenticated" response. To address this, the auth middleware should typically be configured to allow for guest access in the case of email verification, or the route should not include the auth middleware at all.