[Feature Request]: Unify `auth` controller governance

[dmohns]

Preflight Checklist

• I have read the Contributing Guidelines for this project, if it exists.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

In our (backend) code base there is currently no single point of truth for auth governance.

• Some routes define a auth middleware in their route definition, for example solar-home-systems
• Other routes, don't for example e-bikes

How does this even work?

It does because the UserDefaultDatabaseConnectionMiddleware effectively re-implements the auth-gate logic again, by calling $guard = auth('agent_api'); and $guard = auth('api'); hardcodedly.

This creates ambiguity and confusion amongst developers. There should be one and only one plays that defines the auth structure.

Proposed Solution

Please use the route definition as source of truth for auth-gates. Every route should define their correct auth middle ware

For example like so

Route::group(['prefix' => 'e-bikes', 'middleware' => 'auth:api'], static function () {
    Route::get('/', [EBikeController::class, 'index']);
    Route::post('/', [EBikeController::class, 'store']);
    Route::get('/search', [EBikeController::class, 'search']);
    Route::get('/{serialNumber}', [EBikeController::class, 'show']);
    Route::post('/switch', [EBikeController::class, 'switch']);
});

This seems to be the most idiomatic approach in Laravel world. That let Laravel’s auth system flow naturally through middleware + policies/gates.

Then, change UserDefaultDatabaseConnectionMiddleware to apply it's logic based on the available auth middleware, instead of hardcoding routes.

Alternatives Considered

N/A

Additional Information

No response