The word 'web' is currently used with multiple, different meanings in similar contexts, which is not intuitive and can confuse users.
Currently web is used by default as:
the name of the default route file: routes/web.php
a middleware group as defined in Http/Kernel.php
the default guard as defined in config/auth.php
I think my biggest problem with it is the name of the guard, because the naming logic immediately breaks down when a new 'web-like' guard (e.g. admins) is added. Now you have two guards that access the website and one is called web and the other admin/author/whatever, something seemingly not related to its related guard. Adding a new guard for a new provider seems to be the most common use case for guards and it requires immediate changes to the defaults. If you don't rename the web guard, and add these guards to your routes file you get this:
Now when debugging you keep seeing web pop up when you are looking at admin routes. The definition of web becomes muddled. It doesn't help that the web middleware group is usually something you don't look at and don't have to touch, which means new users can't contextualize its function.
My initial proposal is to rename the default guard in config/auth.php to 'users'. This falls in line to how new guards are named ('admin' provider will be accessed through a guard named 'admin'). It would have the same name of the provider, but the provider name doesn't leak out elsewhere so when 'users' is used it can only refer to the guard.
The word 'web' is currently used with multiple, different meanings in similar contexts, which is not intuitive and can confuse users.
Currently web is used by default as:
routes/web.phpHttp/Kernel.phpconfig/auth.phpI think my biggest problem with it is the name of the guard, because the naming logic immediately breaks down when a new 'web-like' guard (e.g. admins) is added. Now you have two guards that access the website and one is called web and the other admin/author/whatever, something seemingly not related to its related guard. Adding a new guard for a new provider seems to be the most common use case for guards and it requires immediate changes to the defaults. If you don't rename the web guard, and add these guards to your routes file you get this:
web.php:
Route::get('/login', [ LoginController::class, 'create' ])->middleware([ 'web', 'guest:web' ];Uh oh, now we've got two uses of web as middleware on the same route. Or even more confusing if you've been diving into guards for a day:
Route::get('/login', [ LoginController::class, 'create' ])->middleware([ 'web', 'guest:admin' ];Now when debugging you keep seeing
webpop up when you are looking at admin routes. The definition of web becomes muddled. It doesn't help that the web middleware group is usually something you don't look at and don't have to touch, which means new users can't contextualize its function.My initial proposal is to rename the default guard in
config/auth.phpto 'users'. This falls in line to how new guards are named ('admin' provider will be accessed through a guard named 'admin'). It would have the same name of the provider, but the provider name doesn't leak out elsewhere so when 'users' is used it can only refer to the guard.