En este artículo veremos cómo migrar la autenticación de un proyecto desde HTTPS con token hacia SSH, cómo validar que la conexión funcione correctamente y qué hacer cuando Git no permite cambiar de rama porque existen archivos locales modificados, como puede pasar con archivos de configuración en Laravel.

El problema: el token de acceso ya venció

Supongamos que tenemos un proyecto Laravel en un servidor de pruebas o demo. Al intentar ejecutar comandos como git fetch, git pull o git checkout, GitHub responde con un error de autenticación porque el token que se usaba anteriormente ya venció.

En muchos casos, aunque ya hayamos creado una llave SSH en el servidor, Git seguirá usando el token anterior si el repositorio todavía tiene configurada una URL remota con HTTPS.

Es decir, crear una llave SSH no cambia automáticamente la forma en que Git se conecta al repositorio. También debemos actualizar la URL remota del proyecto.

1. Revisar la URL remota actual

Primero debemos entrar a la carpeta del proyecto y revisar qué URL remota está usando Git.

cd /ruta/general/del/proyecto

git remote -v

Si la respuesta muestra una URL similar a esta:

origin  https://github.com/usuario/repositorio.git (fetch)
origin  https://github.com/usuario/repositorio.git (push)

significa que el proyecto todavía está usando HTTPS.

En algunos casos, incluso puede aparecer un token dentro de la URL, algo parecido a esto:

origin  https://TOKEN@github.com/usuario/repositorio.git

Ese es el escenario que debemos corregir.

2. Cambiar la URL remota de HTTPS a SSH

Para que Git use la llave SSH, debemos cambiar la URL remota del repositorio usando el comando git remote set-url.

git remote set-url origin git@github.com:usuario/repositorio.git

Este comando cambia el origen del repositorio para que Git deje de usar HTTPS y empiece a usar SSH.

Después podemos verificar nuevamente la configuración:

git remote -v

La salida esperada sería algo como:

origin  git@github.com:usuario/repositorio.git (fetch)
origin  git@github.com:usuario/repositorio.git (push)

3. Probar la conexión SSH con GitHub

Antes de intentar descargar ramas o actualizar el proyecto, conviene probar que la llave SSH realmente esté funcionando.

ssh -T git@github.com

Si la autenticación es correcta, GitHub responderá con un mensaje indicando que la conexión fue exitosa, aunque no permita acceso de shell. Esto es normal.

Una respuesta esperada puede ser similar a:

Hi usuario! You've successfully authenticated, but GitHub does not provide shell access.

Con eso confirmamos que la autenticación SSH ya está funcionando.

4. Descargar información actualizada del repositorio

Una vez configurada la URL SSH, podemos ejecutar:

git fetch origin

Este comando descarga la información actualizada de las ramas remotas sin mezclar cambios todavía en la rama actual.

5. Cambiar a una rama remota

Si necesitamos crear una rama local a partir de una rama remota, podemos usar:

git checkout -b nombre-rama origin/nombre-rama

Sin embargo, en proyectos reales puede aparecer un error indicando que un archivo local tiene cambios y que Git necesita sobrescribirlo para cambiar de rama.

Un caso común en Laravel puede ser un archivo como:

config/app.php

6. ¿Por qué pasa este error?

Git protege los cambios locales para evitar que se pierdan accidentalmente. Si tenemos modificaciones en un archivo y la rama a la que queremos cambiar también modifica ese archivo, Git detiene el proceso.

A veces se intenta usar el comando assume-unchanged para que Git ignore temporalmente un archivo:

git update-index --assume-unchanged config/app.php

Este comando puede ayudar en algunos escenarios locales, pero no es una solución ideal para manejar archivos de configuración modificados en servidores o ambientes de demo.

Además, aunque un archivo esté marcado como assume-unchanged, Git aún puede bloquear operaciones si necesita proteger cambios locales antes de cambiar de rama.

7. Revisar si un archivo está marcado como assume-unchanged

Podemos revisar el estado del archivo con:

git ls-files -v config/app.php

Si el archivo aparece con una letra minúscula al inicio, significa que está marcado como assume-unchanged.

8. Quitar assume-unchanged

Antes de resolver el conflicto, es recomendable quitar esa marca para que Git vuelva a tratar el archivo normalmente.

git update-index --no-assume-unchanged config/app.php

9. Opción segura: guardar temporalmente los cambios con stash

Si necesitamos conservar los cambios locales del archivo, podemos guardarlos temporalmente con git stash.

git stash push -m "Backup config app" -- config/app.php

Después ya podemos intentar cambiar de rama:

git checkout -b nombre-rama origin/nombre-rama

Y si necesitamos recuperar los cambios guardados:

git stash pop

Si al recuperar los cambios aparecen conflictos, deberán resolverse manualmente.

10. Opción rápida: descartar cambios locales

Si los cambios locales no son importantes, podemos descartarlos.

git restore config/app.php

Después intentamos nuevamente cambiar de rama:

git checkout -b nombre-rama origin/nombre-rama

Esta opción debe usarse con cuidado, porque elimina los cambios locales del archivo.

11. Mejor práctica en Laravel: usar .env para configuración por ambiente

En Laravel, lo más recomendable es evitar modificar archivos como config/app.php directamente en cada servidor. Si una configuración cambia dependiendo del ambiente, lo ideal es manejarla desde el archivo .env.

Por ejemplo, en lugar de dejar un valor fijo dentro de config/app.php, podemos leerlo desde una variable de entorno:

'custom_product' => env('APP_CUSTOM_PRODUCT', false),

Y en el archivo .env del servidor:

APP_CUSTOM_PRODUCT=true

De esta manera cada ambiente puede tener su propia configuración sin modificar archivos versionados en Git.

12. Flujo recomendado completo

Un flujo seguro para este tipo de situación sería:

cd /ruta/general/del/proyecto

git remote -v

git remote set-url origin git@github.com:usuario/repositorio.git

git remote -v

ssh -T git@github.com

git fetch origin

git update-index --no-assume-unchanged config/app.php

git stash push -m "Backup config app" -- config/app.php

git checkout -b nombre-rama origin/nombre-rama

Si después necesitamos recuperar los cambios locales:

git stash pop

Conclusión

Cuando un proyecto deja de autenticarse con GitHub porque venció un access token, una buena solución es migrar la conexión del repositorio a SSH. Para que esto funcione, no basta con crear la llave SSH: también debemos cambiar la URL remota del repositorio.

Además, si Git bloquea un cambio de rama por archivos modificados, debemos decidir si queremos conservar esos cambios con git stash o descartarlos con git restore.

En proyectos Laravel, la recomendación más limpia es mantener los archivos de configuración versionados sin modificaciones locales y mover los valores específicos de cada ambiente al archivo .env. Esto evita conflictos, mejora el flujo de despliegue y reduce errores al trabajar con ramas en Git.

Si necesitas ayuda para crear un proyecto de software en Maria Tech contamos con los expertos para apoyarte.

Sin embargo, cuando el formulario se envía por medio de Ajax, especialmente desde modales o componentes dinámicos, surge una duda común: ¿cómo devolvemos los errores de validación en formato JSON sin dejar de usar la estructura nativa de Laravel?

En este artículo veremos una forma práctica de trabajar con Request validation con formularios Ajax, respuestas JSON y códigos HTTP correctos.

El problema común

En un formulario tradicional, si la validación falla, Laravel redirige automáticamente al usuario a la página anterior y muestra los errores en la vista.

Pero cuando usamos Ajax, no queremos una redirección. Queremos una respuesta JSON que podamos procesar desde JavaScript para mostrar los errores dentro de un modal, un toast o una alerta.

Una solución rápida suele ser hacer la validación directamente en el controlador:

$validator = Validator::make($request->all(), $rules, $messages);

if ($validator->fails()) {
    return response()->json([
        'success' => false,
        'errors' => $validator->errors()->all(),
    ], 422);
}

Aunque esto funciona, tiene una desventaja importante: la validación queda mezclada dentro del controlador. Conforme el proyecto crece, esto vuelve el código más difícil de mantener.

La mejor opción: seguir usando Form Request

Laravel permite seguir usando Form Requests aun cuando el formulario se envía por Ajax. Lo único que necesitamos es personalizar la respuesta cuando la validación falla.

Primero, podemos crear un Form Request:

php artisan make:request Admin/User/StoreUserRequest

Luego definimos las reglas de validación:

namespace App\Http\Requests\Admin\User;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Validation\Rule;

class StoreUserRequest extends FormRequest
{
    public function authorize(): bool
    {
        return true;
    }

    public function rules(): array
    {
        return [
            'name' => ['required', 'string', 'max:255'],
            'last_name' => ['required', 'string', 'max:255'],
            'email' => ['required', 'email', 'max:255', Rule::unique('users', 'email')],
            'phone' => ['nullable', 'digits:10'],
            'id_profile_type' => ['required', 'exists:profile_types,id'],
            'password' => ['required', 'string', 'min:8', 'confirmed'],
            'enabled' => ['nullable', 'boolean'],
        ];
    }
}

Personalizar la respuesta JSON de validación

Por defecto, Laravel devuelve los errores agrupados por campo:

{
    "message": "The given data was invalid.",
    "errors": {
        "email": [
            "Este correo electrónico ya está registrado."
        ],
        "password": [
            "La contraseña debe tener al menos 8 caracteres."
        ]
    }
}

Este formato es útil cuando queremos marcar errores campo por campo. Pero si nuestra interfaz usa modales y queremos mostrar una lista general de errores, puede ser más cómodo devolver una lista plana.

Para eso podemos sobrescribir el método failedValidation dentro del StoreUserRequest:

use Illuminate\Contracts\Validation\Validator;
use Illuminate\Http\Exceptions\HttpResponseException;

protected function failedValidation(Validator $validator): void
{
    throw new HttpResponseException(response()->json([
        'success' => false,
        'message' => 'Hay errores en el formulario.',
        'errors' => $validator->errors()->all(),
    ], 422));
}

Con esto, la respuesta quedará así:

{
    "success": false,
    "message": "Hay errores en el formulario.",
    "errors": [
        "El nombre es obligatorio.",
        "Este correo electrónico ya está registrado.",
        "La contraseña debe tener al menos 8 caracteres."
    ]
}

Controlador limpio usando el Form Request

Una vez que el Form Request está listo, el controlador puede mantenerse limpio:

use App\Http\Requests\Admin\User\StoreUserRequest;
use App\Models\User;
use Illuminate\Http\JsonResponse;
use Illuminate\Support\Facades\Hash;
use Throwable;

public function store(StoreUserRequest $request): JsonResponse
{
    try {
        $validated = $request->validated();

        $user = User::create([
            'name' => $validated['name'],
            'last_name' => $validated['last_name'],
            'email' => $validated['email'],
            'phone' => $validated['phone'] ?? null,
            'id_profile_type' => $validated['id_profile_type'],
            'password' => Hash::make($validated['password']),
            'enabled' => $validated['enabled'] ?? 1,
        ]);

        return response()->json([
            'success' => true,
            'message' => 'Usuario registrado correctamente.',
            'user_id' => $user->id,
        ], 201);

    } catch (Throwable $e) {
        report($e);

        return response()->json([
            'success' => false,
            'message' => 'No fue posible registrar el usuario. Inténtalo nuevamente.',
        ], 500);
    }
}

Códigos HTTP recomendados

Es importante regresar códigos HTTP correctos para que el frontend pueda interpretar bien la respuesta.

• 200: operación correcta.
• 201: registro creado correctamente.
• 401: usuario no autenticado.
• 403: usuario autenticado, pero sin permisos.
• 404: recurso no encontrado.
• 422: error de validación.
• 500: error inesperado del servidor.

Para formularios Ajax, una convención práctica sería:

Validación fallida  → 422
Creación correcta   → 201
Actualización       → 200
Eliminación         → 200
No encontrado       → 404
Sin permisos        → 403
Error inesperado    → 500

Conclusión

Usar Form Requests con formularios Ajax es una forma limpia y profesional de validar datos en Laravel sin sacrificar la experiencia de usuario.

La clave está en no llevar las reglas de validación al controlador, sino mantenerlas dentro del Request y personalizar la respuesta JSON cuando la validación falla.

Con esta estructura logramos:

• Controladores más limpios.
• Validaciones reutilizables.
• Respuestas JSON consistentes.
• Códigos HTTP correctos.
• Mejor integración con formularios en modales.
• Mejor experiencia de usuario usando Ajax.

Esta forma de trabajo es especialmente útil en paneles administrativos, sistemas internos, CRMs, ERPs y plataformas donde los formularios se muestran en modales o secciones dinámicas.

Si necesitas ayuda para crear un proyecto de software en Maria Tech contamos con los expertos para apoyarte.

En este artículo veremos cómo estructurar un proceso de recuperación de contraseña en Laravel 13 para dos tipos de usuarios: administradores y clientes. El objetivo es mantener una arquitectura limpia, segura y fácil de mantener.

Contexto del problema

Laravel Breeze instala un sistema de autenticación funcional, pero por defecto está pensado para trabajar principalmente con una sola tabla de usuarios, normalmente users.

Sin embargo, en proyectos más completos podemos necesitar algo como esto:

• Administradores: usuarios internos del sistema, almacenados en la tabla users.
• Clientes: usuarios externos que acceden al sitio o portal del cliente, almacenados en la tabla customers.

En este escenario no conviene mezclar ambos tipos de usuario en la misma tabla, porque normalmente tienen permisos, vistas, reglas de negocio y flujos diferentes.

Estructura recomendada

app/
├── Http/
│   ├── Controllers/
│   │   ├── Admin/
│   │   │   └── Auth/
│   │   │       ├── PasswordResetLinkController.php
│   │   │       └── NewPasswordController.php
│   │   └── Customer/
│   │       └── Auth/
│   │           ├── PasswordResetLinkController.php
│   │           └── NewPasswordController.php

resources/
├── views/
│   ├── admin/
│   │   └── auth/
│   │       ├── forgot-password.blade.php
│   │       └── reset-password.blade.php
│   └── customer/
│       └── auth/
│           ├── forgot-password.blade.php
│           └── reset-password.blade.php

routes/
├── admin.php
└── customer.php

La idea es separar cada flujo para evitar dependencias innecesarias y tener rutas, controladores, vistas y brokers independientes.

Configuración de autenticación

En config/auth.php podemos definir un guard y un provider para cada tipo de usuario.

<?php

use App\Models\User;
use App\Models\Customer;

return [

    'defaults' => [
        'guard' => 'web',
        'passwords' => 'users',
    ],

    'guards' => [
        'web' => [
            'driver' => 'session',
            'provider' => 'users',
        ],

        'customer' => [
            'driver' => 'session',
            'provider' => 'customers',
        ],
    ],

    'providers' => [
        'users' => [
            'driver' => 'eloquent',
            'model' => User::class,
        ],

        'customers' => [
            'driver' => 'eloquent',
            'model' => Customer::class,
        ],
    ],

    'passwords' => [
        'users' => [
            'provider' => 'users',
            'table' => 'password_reset_tokens',
            'expire' => 60,
            'throttle' => 60,
        ],

        'customers' => [
            'provider' => 'customers',
            'table' => 'customer_password_reset_tokens',
            'expire' => 60,
            'throttle' => 60,
        ],
    ],

];

El punto clave está en la sección passwords. Ahí definimos dos brokers: users para administradores y customers para clientes. Cada broker usa su propio provider y su propia tabla de tokens.

Migración para tokens de clientes

Schema::create('customer_password_reset_tokens', function (Blueprint $table) {
    $table->string('email')->primary();
    $table->string('token');
    $table->timestamp('created_at')->nullable();
});

Esto permite que el flujo de administradores y clientes quede completamente separado.

Rutas para administradores

use App\Http\Controllers\Admin\Auth\PasswordResetLinkController;
use App\Http\Controllers\Admin\Auth\NewPasswordController;
use Illuminate\Support\Facades\Route;

Route::middleware('admin.guest')->group(function () {
    Route::get('/forgot-password', [PasswordResetLinkController::class, 'create'])
        ->name('password.request');

    Route::post('/forgot-password', [PasswordResetLinkController::class, 'store'])
        ->name('password.email');

    Route::get('/reset-password/{token}', [NewPasswordController::class, 'create'])
        ->name('password.reset');

    Route::post('/reset-password', [NewPasswordController::class, 'store'])
        ->name('password.store');
});

Rutas para clientes

use App\Http\Controllers\Customer\Auth\PasswordResetLinkController;
use App\Http\Controllers\Customer\Auth\NewPasswordController;
use Illuminate\Support\Facades\Route;

Route::middleware('customer.guest')->group(function () {
    Route::get('/forgot-password', [PasswordResetLinkController::class, 'create'])
        ->name('password.request');

    Route::post('/forgot-password', [PasswordResetLinkController::class, 'store'])
        ->name('password.email');

    Route::get('/reset-password/{token}', [NewPasswordController::class, 'create'])
        ->name('password.reset');

    Route::post('/reset-password', [NewPasswordController::class, 'store'])
        ->name('password.store');
});

Controlador para enviar el enlace de recuperación

El controlador encargado de enviar el enlace de recuperación debe usar el broker correcto.

Administrador

namespace App\Http\Controllers\Admin\Auth;

use App\Http\Controllers\Controller;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Password;
use Illuminate\Validation\ValidationException;

class PasswordResetLinkController extends Controller
{
    public function create()
    {
        return view('admin.auth.forgot-password');
    }

    public function store(Request $request)
    {
        $request->validate([
            'email' => ['required', 'email'],
        ]);

        $status = Password::broker('users')->sendResetLink(
            $request->only('email')
        );

        if ($status === Password::RESET_LINK_SENT) {
            return back()->with('status', __($status));
        }

        throw ValidationException::withMessages([
            'email' => __($status),
        ]);
    }
}

Cliente

namespace App\Http\Controllers\Customer\Auth;

use App\Http\Controllers\Controller;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Password;
use Illuminate\Validation\ValidationException;

class PasswordResetLinkController extends Controller
{
    public function create()
    {
        return view('customer.auth.forgot-password');
    }

    public function store(Request $request)
    {
        $request->validate([
            'email' => ['required', 'email'],
        ]);

        $status = Password::broker('customers')->sendResetLink(
            $request->only('email')
        );

        if ($status === Password::RESET_LINK_SENT) {
            return back()->with('status', __($status));
        }

        throw ValidationException::withMessages([
            'email' => __($status),
        ]);
    }
}

El cambio central es el broker:

Password::broker('users')      // Administradores
Password::broker('customers')  // Clientes

Controlador para actualizar la contraseña

Administrador

namespace App\Http\Controllers\Admin\Auth;

use App\Http\Controllers\Controller;
use Illuminate\Auth\Events\PasswordReset;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Facades\Password;
use Illuminate\Support\Str;
use Illuminate\Validation\Rules;

class NewPasswordController extends Controller
{
    public function create(Request $request)
    {
        return view('admin.auth.reset-password', [
            'request' => $request,
        ]);
    }

    public function store(Request $request)
    {
        $request->validate([
            'token' => ['required'],
            'email' => ['required', 'email'],
            'password' => ['required', 'confirmed', Rules\Password::defaults()],
        ]);

        $status = Password::broker('users')->reset(
            $request->only('email', 'password', 'password_confirmation', 'token'),
            function ($user) use ($request) {
                $user->forceFill([
                    'password' => Hash::make($request->password),
                    'remember_token' => Str::random(60),
                ])->save();

                event(new PasswordReset($user));
            }
        );

        return $status === Password::PASSWORD_RESET
            ? redirect()->route('admin.login')->with('status', __($status))
            : back()->withInput($request->only('email'))
                ->withErrors(['email' => __($status)]);
    }
}

Cliente

namespace App\Http\Controllers\Customer\Auth;

use App\Http\Controllers\Controller;
use Illuminate\Auth\Events\PasswordReset;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Hash;
use Illuminate\Support\Facades\Password;
use Illuminate\Support\Str;
use Illuminate\Validation\Rules;

class NewPasswordController extends Controller
{
    public function create(Request $request)
    {
        return view('customer.auth.reset-password', [
            'request' => $request,
        ]);
    }

    public function store(Request $request)
    {
        $request->validate([
            'token' => ['required'],
            'email' => ['required', 'email'],
            'password' => ['required', 'confirmed', Rules\Password::defaults()],
        ]);

        $status = Password::broker('customers')->reset(
            $request->only('email', 'password', 'password_confirmation', 'token'),
            function ($customer) use ($request) {
                $customer->forceFill([
                    'password' => Hash::make($request->password),
                    'remember_token' => Str::random(60),
                ])->save();

                event(new PasswordReset($customer));
            }
        );

        return $status === Password::PASSWORD_RESET
            ? redirect()->route('customer.login')->with('status', __($status))
            : back()->withInput($request->only('email'))
                ->withErrors(['email' => __($status)]);
    }
}

Personalizar la URL del correo de recuperación

Un detalle importante es que Laravel genera el enlace de recuperación usando una notificación. Si no personalizamos ese enlace, puede terminar enviando al usuario al flujo equivocado.

Para resolverlo, podemos agregar la lógica en app/Providers/AppServiceProvider.php.

namespace App\Providers;

use App\Models\Customer;
use App\Models\User;
use Illuminate\Auth\Notifications\ResetPassword;
use Illuminate\Support\Facades\URL;
use Illuminate\Support\ServiceProvider;

class AppServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        //
    }

    public function boot(): void
    {
        ResetPassword::createUrlUsing(function (object $notifiable, string $token): string {
            if ($notifiable instanceof Customer) {
                return URL::route('customer.password.reset', [
                    'token' => $token,
                    'email' => $notifiable->getEmailForPasswordReset(),
                ]);
            }

            if ($notifiable instanceof User) {
                return URL::route('admin.password.reset', [
                    'token' => $token,
                    'email' => $notifiable->getEmailForPasswordReset(),
                ]);
            }

            return URL::route('customer.password.reset', [
                'token' => $token,
                'email' => $notifiable->getEmailForPasswordReset(),
            ]);
        });
    }
}

Con esto, cuando el modelo sea User, Laravel enviará al flujo de administrador. Cuando el modelo sea Customer, enviará al flujo de cliente.

Vistas de recuperación de contraseña

En cada formulario es importante apuntar a la ruta correcta.

Formulario para solicitar enlace

Administrador:

<form method="POST" action="{{ route('admin.password.email') }}">
    @csrf
    <input type="email" name="email" required>
    <button type="submit">
        Enviar enlace
    </button>
</form>

Cliente:

<form method="POST" action="{{ route('customer.password.email') }}">
    @csrf
    <input type="email" name="email" required>
    <button type="submit">
        Enviar enlace
    </button>
</form>

Formulario para crear nueva contraseña

Administrador:

<form method="POST" action="{{ route('admin.password.store') }}">
    @csrf
    <input type="hidden" name="token" value="{{ $request->route('token') }}">
    <input type="email" name="email" value="{{ old('email', $request->email) }}" required>
    <input type="password" name="password" required>
    <input type="password" name="password_confirmation" required>
    <button type="submit">
        Actualizar contraseña
    </button>
</form>

Cliente:

<form method="POST" action="{{ route('customer.password.store') }}">
    @csrf
    <input type="hidden" name="token" value="{{ $request->route('token') }}">
    <input type="email" name="email" value="{{ old('email', $request->email) }}" required>
    <input type="password" name="password" required>
    <input type="password" name="password_confirmation" required>
    <button type="submit">
        Actualizar contraseña
    </button>
</form>

Buenas prácticas

• Usar modelos separados cuando los usuarios internos y externos tienen responsabilidades diferentes.
• Separar rutas, vistas y controladores por tipo de usuario.
• Usar un broker de contraseña diferente para cada tabla.
• Personalizar la URL del correo para evitar que el usuario llegue al flujo equivocado.
• No depender completamente de la estructura por defecto de Breeze cuando el proyecto requiere múltiples áreas de autenticación.
• Mantener nombres claros como Admin y Customer para facilitar el mantenimiento.

Conclusión

La recuperación de contraseña para múltiples tipos de usuarios en Laravel requiere separar correctamente guards, providers, brokers, rutas, controladores y vistas. Aunque Breeze ofrece una buena base inicial, en proyectos con administradores y clientes conviene tomar el control del flujo para evitar cruces entre autenticaciones.

La clave está en usar un broker distinto para cada tipo de usuario:

Password::broker('users')      // Administradores
Password::broker('customers')  // Clientes

Y personalizar el enlace generado por correo desde AppServiceProvider, para que cada usuario llegue al formulario correcto.

Con esta estructura, el sistema queda más limpio, seguro y preparado para crecer.

¡Si te ha servido de algo este artículo no olvides dejarnos un comentario!

En este artículo veremos cómo estructurar en Laravel una autenticación separada para dos tipos de usuarios: administradores y clientes. La idea es mantener una arquitectura limpia, segura y fácil de mantener.

Contexto del proyecto

El escenario es el siguiente:

• El administrador accede desde una URL privada, por ejemplo: /admin.
• Los clientes acceden desde el sitio público, por ejemplo: /.
• Los administradores se almacenan en la tabla users.
• Los clientes se almacenan en la tabla customers.
• Cada sección usa vistas, layouts, assets y controladores separados.
• Se utiliza Laravel Breeze como punto de partida, pero se adapta la estructura para soportar dos autenticaciones independientes.

La decisión principal fue no mezclar administradores y clientes en una misma tabla, ya que tienen responsabilidades, permisos y flujos completamente diferentes.

Estructura recomendada del proyecto

Una estructura limpia puede organizarse así:

app/
├── Http/
│   ├── Controllers/
│   │   ├── Admin/
│   │   │   ├── Auth/
│   │   │   └── DashboardController.php
│   │   │
│   │   ├── Customer/
│   │   │   ├── Auth/
│   │   │   └── AccountController.php
│   │   │
│   │   └── Controller.php
│   │
│   ├── Requests/
│   │   ├── Admin/
│   │   │   └── Auth/
│   │   │       └── LoginRequest.php
│   │   │
│   │   └── Customer/
│   │       └── Auth/
│   │           └── LoginRequest.php
│
resources/
├── views/
│   ├── admin/
│   │   ├── auth/
│   │   ├── layouts/
│   │   └── dashboard/
│   │
│   └── customer/
│       ├── auth/
│       ├── layouts/
│       └── account/
│
routes/
├── admin.php
├── customer.php
├── web.php
└── console.php

public/
└── assets/
    ├── admin/
    └── customer/

Esta separación permite que cada sección tenga su propia lógica, sus propios recursos visuales y sus propios middlewares.

Configuración de guards y providers

Laravel permite manejar múltiples sistemas de autenticación mediante guards y providers.

En este caso usamos:

• web para administradores.
• customer para clientes.

La configuración se realiza en config/auth.php:

<?php

use App\Models\User;
use App\Models\Customer;

return [

    'defaults' => [
        'guard' => env('AUTH_GUARD', 'web'),
        'passwords' => env('AUTH_PASSWORD_BROKER', 'users'),
    ],

    'guards' => [
        'web' => [
            'driver' => 'session',
            'provider' => 'users',
        ],

        'customer' => [
            'driver' => 'session',
            'provider' => 'customers',
        ],
    ],

    'providers' => [
        'users' => [
            'driver' => 'eloquent',
            'model' => User::class,
        ],

        'customers' => [
            'driver' => 'eloquent',
            'model' => Customer::class,
        ],
    ],

    'passwords' => [
        'users' => [
            'provider' => 'users',
            'table' => env('AUTH_PASSWORD_RESET_TOKEN_TABLE', 'password_reset_tokens'),
            'expire' => 60,
            'throttle' => 60,
        ],

        'customers' => [
            'provider' => 'customers',
            'table' => env('CUSTOMER_AUTH_PASSWORD_RESET_TOKEN_TABLE', 'customer_password_reset_tokens'),
            'expire' => 60,
            'throttle' => 60,
        ],
    ],

    'password_timeout' => env('AUTH_PASSWORD_TIMEOUT', 10800),

];

Un detalle importante es no usar la misma variable AUTH_MODEL para ambos providers, porque podría provocar que los clientes intenten autenticarse con el modelo de usuarios administrativos.

Modelo Customer autenticable

El modelo de cliente no debe extender directamente de Model, sino de Authenticatable, igual que el modelo User.

<?php

namespace App\Models;

use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;

class Customer extends Authenticatable
{
    use Notifiable;

    protected $guard = 'customer';

    protected $fillable = [
        'name',
        'last_name',
        'phone',
        'email',
        'password',
        'enabled',
    ];

    protected $hidden = [
        'password',
        'remember_token',
    ];
}

Esto permite que Laravel pueda autenticar clientes usando el guard customer.

Migraciones principales

Para los clientes se puede crear una tabla independiente:

Schema::create('customers', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->string('last_name');
    $table->char('phone', 10)->nullable();
    $table->string('email')->unique();
    $table->timestamp('email_verified_at')->nullable();
    $table->string('password');
    $table->rememberToken();
    $table->tinyInteger('enabled')->default(1);
    $table->timestamps();
});

También se puede manejar una tabla independiente para recuperación de contraseñas:

Schema::create('customer_password_reset_tokens', function (Blueprint $table) {
    $table->string('email')->primary();
    $table->string('token');
    $table->timestamp('created_at')->nullable();
});

En cuanto a sesiones, no es obligatorio crear una tabla diferente para clientes. Laravel usa la tabla sessions para guardar la sesión del navegador, no una sesión independiente por guard.

Rutas separadas

Una buena práctica es separar las rutas del administrador y del cliente.

Ejemplo de routes/admin.php:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\Admin\Auth\AuthenticatedSessionController;
use App\Http\Controllers\Admin\DashboardController;

Route::middleware('admin.guest')->group(function () {
    Route::get('/login', [AuthenticatedSessionController::class, 'create'])
        ->name('login');

    Route::post('/login', [AuthenticatedSessionController::class, 'store'])
        ->name('login.store');
});

Route::middleware('admin.auth')->group(function () {
    Route::get('/dashboard', [DashboardController::class, 'index'])
        ->name('dashboard');

    Route::post('/logout', [AuthenticatedSessionController::class, 'destroy'])
        ->name('logout');
});

Ejemplo de routes/customer.php:

use Illuminate\Support\Facades\Route;
use App\Http\Controllers\Customer\Auth\AuthenticatedSessionController;
use App\Http\Controllers\Customer\HomeController;
use App\Http\Controllers\Customer\AccountController;

Route::get('/', [HomeController::class, 'index'])
    ->name('home');

Route::middleware('customer.guest')->group(function () {
    Route::get('/login', [AuthenticatedSessionController::class, 'create'])
        ->name('login');

    Route::post('/login', [AuthenticatedSessionController::class, 'store'])
        ->name('login.store');
});

Route::middleware('customer.auth')->group(function () {
    Route::get('/mi-cuenta', [AccountController::class, 'index'])
        ->name('account');

    Route::post('/logout', [AuthenticatedSessionController::class, 'destroy'])
        ->name('logout');
});

Cargar rutas desde bootstrap/app.php

En Laravel moderno, las rutas adicionales pueden registrarse desde bootstrap/app.php:

use Illuminate\Support\Facades\Route;

->withRouting(
    web: __DIR__.'/../routes/web.php',
    commands: __DIR__.'/../routes/console.php',
    then: function () {
        Route::middleware('web')
            ->prefix('admin')
            ->name('admin.')
            ->group(base_path('routes/admin.php'));

        Route::middleware('web')
            ->name('customer.')
            ->group(base_path('routes/customer.php'));
    },
)

Con esta configuración se obtienen rutas como:

• /admin/login → admin.login
• /admin/dashboard → admin.dashboard
• /login → customer.login
• /mi-cuenta → customer.account

Middlewares propios por tipo de usuario

Para evitar lógica condicional dentro de bootstrap/app.php, se pueden crear middlewares específicos para cada sección.

Por ejemplo:

• admin.auth: valida que el usuario admin esté autenticado y activo.
• admin.guest: evita que un admin autenticado vuelva al login.
• customer.auth: valida que el cliente esté autenticado y activo.
• customer.guest: evita que un cliente autenticado vuelva al login.

Middleware de administrador autenticado:

<?php

namespace App\Http\Middleware\Admin;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use Symfony\Component\HttpFoundation\Response;

class EnsureAdminIsAuthenticated
{
    public function handle(Request $request, Closure $next): Response
    {
        if (! Auth::guard('web')->check()) {
            return redirect()->route('admin.login');
        }

        $user = Auth::guard('web')->user();

        if (! $user->enabled) {
            Auth::guard('web')->logout();

            $request->session()->invalidate();
            $request->session()->regenerateToken();

            return redirect()
                ->route('admin.login')
                ->withErrors([
                    'email' => 'Tu cuenta se encuentra deshabilitada.',
                ]);
        }

        return $next($request);
    }
}

Middleware de cliente autenticado:

<?php

namespace App\Http\Middleware\Customer;

use Closure;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Auth;
use Symfony\Component\HttpFoundation\Response;

class EnsureCustomerIsAuthenticated
{
    public function handle(Request $request, Closure $next): Response
    {
        if (! Auth::guard('customer')->check()) {
            return redirect()->route('customer.login');
        }

        $customer = Auth::guard('customer')->user();

        if (! $customer->enabled) {
            Auth::guard('customer')->logout();

            $request->session()->invalidate();
            $request->session()->regenerateToken();

            return redirect()
                ->route('customer.login')
                ->withErrors([
                    'email' => 'Tu cuenta se encuentra deshabilitada.',
                ]);
        }

        return $next($request);
    }
}

Después se registran los alias de middleware en bootstrap/app.php:

use Illuminate\Foundation\Configuration\Middleware;
use App\Http\Middleware\Admin\EnsureAdminIsAuthenticated;
use App\Http\Middleware\Admin\RedirectIfAdminAuthenticated;
use App\Http\Middleware\Customer\EnsureCustomerIsAuthenticated;
use App\Http\Middleware\Customer\RedirectIfCustomerAuthenticated;

->withMiddleware(function (Middleware $middleware): void {
    $middleware->alias([
        'admin.auth' => EnsureAdminIsAuthenticated::class,
        'admin.guest' => RedirectIfAdminAuthenticated::class,

        'customer.auth' => EnsureCustomerIsAuthenticated::class,
        'customer.guest' => RedirectIfCustomerAuthenticated::class,
    ]);
})

LoginRequest para clientes

Uno de los errores más comunes al trabajar con múltiples guards es usar Auth::attempt() sin especificar guard. Cuando se hace eso, Laravel utiliza el guard por defecto, normalmente web.

Para el login de clientes debe usarse:

Auth::guard('customer')->attempt($credentials, $this->boolean('remember'))

Ejemplo:

public function authenticate(): void
{
    $this->ensureIsNotRateLimited();

    $credentials = $this->only('email', 'password');
    $credentials['enabled'] = 1;

    if (! Auth::guard('customer')->attempt($credentials, $this->boolean('remember'))) {
        RateLimiter::hit($this->throttleKey());

        throw ValidationException::withMessages([
            'email' => trans('auth.failed'),
        ]);
    }

    Auth::guard('web')->logout();

    RateLimiter::clear($this->throttleKey());
}

En este ejemplo, después de iniciar sesión como cliente, se cierra cualquier sesión activa del administrador en el mismo navegador.

LoginRequest para administradores

Para el administrador se hace lo mismo, pero usando el guard web:

public function authenticate(): void
{
    $this->ensureIsNotRateLimited();

    $credentials = $this->only('email', 'password');
    $credentials['enabled'] = 1;

    if (! Auth::guard('web')->attempt($credentials, $this->boolean('remember'))) {
        RateLimiter::hit($this->throttleKey());

        throw ValidationException::withMessages([
            'email' => trans('auth.failed'),
        ]);
    }

    Auth::guard('customer')->logout();

    RateLimiter::clear($this->throttleKey());
}

De esta manera se evita que el mismo navegador mantenga una sesión de administrador y una sesión de cliente al mismo tiempo.

Uso correcto en Blade

Otro detalle importante es que la directiva @auth usa el guard por defecto si no se especifica uno. Por eso, en vistas de cliente se debe indicar explícitamente el guard.

Para clientes:

@auth('customer')
    Hola, {{ auth('customer')->user()->name }}
@endauth

@guest('customer')
    <a href="{{ route('customer.login') }}">Iniciar sesión</a>
@endguest

Para administradores:

@auth('web')
    Hola, {{ auth('web')->user()->name }}
@endauth

@guest('web')
    <a href="{{ route('admin.login') }}">Iniciar sesión</a>
@endguest

Sesiones en base de datos

Cuando se usa SESSION_DRIVER=database, Laravel guarda la sesión del navegador en la tabla sessions. Es importante entender que no se crea una sesión independiente por guard.

Si se inicia sesión como administrador y después como cliente en el mismo navegador, Laravel puede seguir usando el mismo registro de sesión. Lo importante es que el guard correcto esté autenticado y el otro haya sido cerrado.

Para validar:

auth('web')->check();   // Admin
auth('customer')->check(); // Cliente

También es normal que el registro en la tabla sessions permanezca por un tiempo aunque el usuario haya cerrado sesión. Laravel limpia las sesiones expiradas según su configuración de expiración.

Extras

Assets separados con Vite

Si cada sección utiliza un template diferente, también conviene separar los assets.

resources/
├── admin/
│   ├── css/
│   │   └── app.css
│   └── js/
│       └── app.js
│
└── customer/
    ├── css/
    │   └── app.css
    └── js/
        └── app.js

Ejemplo de vite.config.js:

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';

export default defineConfig({
    plugins: [
        laravel({
            input: [
                'resources/admin/css/app.css',
                'resources/admin/js/app.js',

                'resources/customer/css/app.css',
                'resources/customer/js/app.js',
            ],
            refresh: true,
        }),
    ],
});

En el layout de administrador:

@vite([
    'resources/admin/css/app.css',
    'resources/admin/js/app.js'
])

En el layout de cliente:

@vite([
    'resources/customer/css/app.css',
    'resources/customer/js/app.js'
])

Conclusión

Implementar autenticación para dos tipos de usuarios en Laravel requiere separar responsabilidades desde el inicio. La clave está en no mezclar modelos, guards, rutas ni vistas.

Una arquitectura limpia para este caso sería:

• users para administradores.
• customers para clientes.
• web como guard de administradores.
• customer como guard de clientes.
• resources/views/admin para el panel administrativo.
• resources/views/customer para el portal público.
• routes/admin.php y routes/customer.php para separar rutas.
• Middlewares propios para controlar accesos y redirecciones.

Esta estructura evita confusiones, mejora la seguridad y permite que el proyecto crezca de forma ordenada.

En sistemas donde existen usuarios internos y clientes finales, separar la autenticación no solo es una buena práctica técnica: también facilita el mantenimiento, las pruebas y la evolución del proyecto.

Esto es muy útil cuando un proyecto requiere una versión específica de PHP o cuando algún paquete de Composer todavía no es compatible con la versión más reciente.

En este artículo veremos cómo instalar y usar una versión diferente de PHP con Laravel Valet, tomando como ejemplo un problema común al instalar paquetes como maatwebsite/excel.

El problema: incompatibilidad entre paquetes y versión de PHP

En nuestro caso, al intentar instalar maatwebsite/excel, Composer mostró un error relacionado con phpoffice/phpspreadsheet:

phpoffice/phpspreadsheet 1.30.4 requires php >=7.4.0 <8.5.0 -> your php version (8.5.5) does not satisfy that requirement.

El mensaje es bastante claro: la versión instalada de PHP era 8.5.5, pero phpoffice/phpspreadsheet en la versión requerida por el proyecto solo permite PHP menor a 8.5.0.

Esto no significa que Laravel Valet esté mal configurado. Simplemente quiere decir que el paquete aún no es compatible con la versión de PHP que estamos usando.

maatwebsite/excel utiliza phpoffice/phpspreadsheet como dependencia para trabajar con archivos Excel y CSV.

¿Por qué conviene cambiar de PHP en lugar de forzar Composer?

Cuando Composer marca un error de compatibilidad, una tentación común es usar banderas como:

composer require paquete --ignore-platform-reqs

Aunque esto puede “saltarse” temporalmente la validación, no es recomendable como solución principal.

El problema es que Composer dejaría instalar un paquete que oficialmente no soporta tu versión de PHP. Eso puede provocar errores más adelante en ejecución, especialmente cuando se trata de librerías que manipulan archivos, fechas, memoria, formatos o extensiones de PHP.

La solución más limpia es usar una versión de PHP compatible con el proyecto.

En este caso, la solución fue bajar de PHP 8.5 a PHP 8.4.

Verificar la versión actual de PHP

Antes de cambiar nada, conviene revisar qué versión está usando nuestra terminal:

php -v

También podemos revisar qué versión de PHP está usando Valet:

valet which-php

Esto ayuda a confirmar si Composer, Laravel y Valet están trabajando con la versión esperada.

Instalar PHP 8.4 con Homebrew

Si estamos usando Valet en macOS, lo normal es instalar PHP mediante Homebrew.

Para instalar PHP 8.4 ejecutamos:

brew install php@8.4

Si ya lo teníamos instalado, podemos asegurarnos de que esté actualizado con:

brew update
brew upgrade php@8.4

Cambiar Laravel Valet a PHP 8.4

Laravel Valet permite cambiar la versión global de PHP con el comando valet use.

Para cambiar Valet a PHP 8.4:

valet use php@8.4

Se reiniciará Valet de manera automática, si no lo hace lo reiniciamos nosotros:

valet restart

Y validamos:

php -v
valet which-php

La salida debería mostrar una versión PHP 8.4.x.

Si la terminal sigue usando otra versión

Puede pasar que Valet ya esté usando PHP 8.4, pero la terminal siga apuntando a PHP 8.5.

En ese caso, podemos forzar el link de Homebrew:

brew unlink php
brew link --force --overwrite php@8.4

Luego volvemos a validar:

php -v

Si todo está correcto, Composer ya debería detectar PHP 8.4.

Instalar nuevamente el paquete

Una vez cambiada la versión de PHP, regresamos al proyecto Laravel:

cd ~/Developments/LaravelProjects/nombre-del-proyecto

Y ejecutamos:

composer require maatwebsite/excel

Si el problema era la incompatibilidad con PHP 8.5, ahora Composer debería poder resolver las dependencias correctamente.

Usar una versión de PHP solo para un proyecto

Una opción muy útil de Valet es aislar una versión de PHP por proyecto.

Esto sirve cuando tenemos varios proyectos con diferentes necesidades. Por ejemplo:

• Un proyecto moderno usando PHP 8.4.
• Un proyecto legacy usando PHP 8.2.
• Un proyecto experimental usando PHP 8.5.

Para aislar un proyecto con PHP 8.4:

cd ~/Developments/LaravelProjects/foresta
valet isolate php@8.4

Para ver los sitios aislados:

valet isolated

Para quitar el aislamiento y volver a usar la versión global de Valet:

valet unisolate

Esta opción es muy práctica porque evita estar cambiando la versión global de PHP cada vez que trabajamos en proyectos distintos.

Crear un archivo .valetrc

Otra alternativa es crear un archivo .valetrc dentro del proyecto indicando la versión de PHP que debe usar.

Dentro del proyecto:

touch .valetrc

Y agregamos:

php=php@8.4

Después podemos ejecutar:

valet use

Valet leerá el archivo y aplicará la versión indicada.

Comandos útiles de diagnóstico

Cuando Composer marque errores de compatibilidad, estos comandos ayudan bastante:

php -v

valet which-php

composer check-platform-reqs

composer why-not maatwebsite/excel

También podemos revisar qué paquetes están bloqueando una instalación específica:

composer why-not phpoffice/phpspreadsheet

Conclusión

Laravel Valet facilita bastante el manejo de versiones de PHP en macOS. Cuando un paquete no es compatible con la versión actual, lo ideal no es forzar Composer, sino revisar los requisitos y utilizar una versión de PHP compatible.

Si vienes de trabajar con herramientas como MAMP, probablemente estés acostumbrado a levantar y apagar servicios manualmente cada vez que desarrollas.

Pero cuando empiezas a trabajar con Laravel Valet, el flujo cambia bastante: todo es más rápido, más limpio y mucho más cómodo para proyectos Laravel en macOS.

En este artículo veremos qué es Laravel Valet, cómo instalarlo, cómo configurarlo y cómo solucionar algunos errores comunes que pueden aparecer durante el proceso.

¿Qué es Laravel Valet?

Laravel Valet es un entorno de desarrollo local para macOS que permite ejecutar proyectos PHP y Laravel sin necesidad de configurar servidores virtuales manualmente.

Valet utiliza principalmente:

• Nginx, como servidor web.
• dnsmasq, para resolver dominios locales.
• PHP, instalado normalmente mediante Homebrew.

Con Valet puedes acceder a tus proyectos usando dominios como:

http://proyecto.test

En lugar de depender de rutas como:

http://localhost:8000

Instalación base de Laravel Valet

Antes de instalar Valet es recomendable contar con:

• Homebrew instalado.
• PHP instalado.
• Composer instalado.

Para instalar Valet ejecutamos:

composer global require laravel/valet

Después inicializamos Valet con:

valet install

Este comando configura los servicios necesarios para que Valet funcione correctamente en segundo plano.

Error común: zsh: command not found: valet

Uno de los errores más comunes después de instalar Valet es:

zsh: command not found: valet

Esto normalmente significa que Valet sí fue instalado, pero la ruta global de Composer no está agregada al PATH del sistema.

Para encontrar la ruta global de Composer ejecutamos:

composer global config bin-dir --absolute

El resultado suele ser algo parecido a:

/Users/tu_usuario/.config/composer/vendor/bin

Después agregamos esa ruta al archivo .zshrc:

nano ~/.zshrc

Y añadimos:

export PATH="$HOME/.config/composer/vendor/bin:$PATH"

Finalmente recargamos la configuración:

source ~/.zshrc

Y validamos:

valet --version

Organización de proyectos con “valet park”

Una de las funciones más útiles de Valet es “valet park".

Este comando le indica a Valet que todos los proyectos dentro de una carpeta deben estar disponibles automáticamente como dominios .test.

Por ejemplo:

cd ~/Developments/LaravelProjects
valet park

Si dentro de esa carpeta tenemos:

tu-proyecto-1
tu-proyecto-2
tu-proyecto-3

Entonces podremos acceder a:

http://tu-proyecto-1.test
http://tu-proyecto-2.test
http://tu-proyecto-3.test

Comandos útiles de Valet

Algunos comandos básicos para controlar Valet son:

valet start

Inicia los servicios de Valet.

valet stop

Detiene los servicios de Valet.

valet restart

Reinicia Valet. Es muy útil cuando algo no responde correctamente.

valet paths

Muestra las carpetas que están configuradas con valet park.

valet forget

Elimina el park de la carpeta actual.

Configuración de Node con nvm

Para trabajar con Laravel moderno también necesitamos Node.js, ya que Laravel usa Vite para compilar CSS y JavaScript.

Una buena práctica es manejar Node con nvm, ya que permite instalar y cambiar versiones fácilmente.

Instalamos nvm con Homebrew:

brew install nvm

Creamos la carpeta de configuración:

mkdir ~/.nvm

Después agregamos esto al archivo .zshrc:

export NVM_DIR="$HOME/.nvm"
source $(brew --prefix nvm)/nvm.sh

Recargamos:

source ~/.zshrc

Instalamos una versión de Node:

nvm install 22
nvm use 22

Y la dejamos como versión por defecto:

nvm alias default 22

Si queremos la última versión estable de Node el comando sería:

nvm install --lts

Error común: env: node: No such file or directory

Este error aparece cuando el sistema no encuentra Node:

env: node: No such file or directory

Generalmente ocurre porque nvm no se cargó correctamente en la terminal.

Para solucionarlo podemos ejecutar:

nvm use default

Y validar:

node -v
npm -v

Si el problema continúa, hay que revisar que la configuración de nvm esté correctamente agregada en ~/.zshrc.

Crear un proyecto Laravel

Para crear proyectos Laravel de forma más rápida podemos instalar el instalador oficial:

composer global require laravel/installer

Este comando habilita el comando:

laravel new nombre-proyecto

Por ejemplo:

cd ~/Developments/LaravelProjects
laravel new tu-proyecto-1

Después podemos abrirlo con:

cd tu-proyecto-1
valet open

Y el proyecto estará disponible en:

http://tu-proyecto-1.test

Frontend con Vite

Laravel utiliza Vite para compilar los archivos CSS y JavaScript del proyecto.

Después de crear el proyecto debemos ejecutar:

npm install
npm run dev

El comando npm install instala las dependencias definidas en package.json.

El comando npm run dev levanta Vite en modo desarrollo, permitiendo compilar assets y trabajar con recarga automática (hot reload).

Error común: Failed to resolve import “./bootstrap”

Este error puede aparecer al ejecutar Vite:

Failed to resolve import "./bootstrap" from "resources/js/app.js"

Significa que Laravel está intentando importar este archivo:

resources/js/bootstrap.js

Pero no existe o no fue generado correctamente.

Primero podemos intentar reinstalar dependencias:

rm -rf node_modules package-lock.json
npm install
npm run dev

Si el archivo sigue sin existir, se puede crear manualmente:

touch resources/js/bootstrap.js

Y agregar:

import axios from 'axios';

window.axios = axios;

window.axios.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';

Error común: Failed to resolve import “axios”

Otro error común es:

Failed to resolve import "axios" from "resources/js/bootstrap.js"

Esto significa que el archivo bootstrap.js intenta importar Axios, pero Axios no está instalado.

La solución es:

npm install axios
npm run dev

Configurar MySQL sin depender de MAMP

Si queremos trabajar sin depender de MAMP, podemos instalar MySQL mediante Homebrew:

brew install mysql

Para iniciar el servicio:

brew services start mysql

Para detenerlo:

brew services stop mysql

Podemos entrar a MySQL con:

mysql -u root

Y crear una base de datos:

CREATE DATABASE tu-proyecto-1 CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Agregar contraseña al usuario root de MySQL

Para asignar contraseña al usuario root podemos ejecutar:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'TuPasswordSeguro123!';
FLUSH PRIVILEGES;

Después configuramos el archivo .env de Laravel:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=tu-proyecto-1
DB_USERNAME=root
DB_PASSWORD=TuPasswordSeguro123!

Error común: Plugin ‘mysql_native_password’ is not loaded

En versiones recientes de MySQL puede aparecer este error:

ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded

Esto ocurre porque MySQL moderno ya no utiliza ese plugin por defecto. Actualmente se usa caching_sha2_password.

La solución es no forzar mysql_native_password y usar:

ALTER USER 'root'@'localhost' IDENTIFIED BY 'TuPasswordSeguro123!';
FLUSH PRIVILEGES;

Flujo recomendado de trabajo

Una vez configurado el entorno, el flujo diario puede ser muy sencillo.

Para iniciar el entorno

brew services start mysql
valet start
cd ~/Developments/LaravelProjects/tu-proyecto-1
npm run dev

Para apagar el entorno

Primero detenemos Vite con:

Ctrl + C

Después detenemos MySQL:

brew services stop mysql

Y opcionalmente Valet:

valet stop

Tip pro: crear alias para iniciar y detener el entorno

Para simplificar el flujo podemos crear alias en ~/.zshrc:

alias up-dev="brew services start mysql && valet start"
alias down-dev="brew services stop mysql && valet stop"

Después recargamos:

source ~/.zshrc

Y ahora podemos iniciar el entorno con:

up-dev

Y apagarlo con:

down-dev

Conclusión

Laravel Valet es una excelente alternativa para desarrollar proyectos Laravel en macOS. Comparado con MAMP, ofrece un flujo más limpio, rápido y cómodo para trabajar con dominios locales, PHP moderno, Composer, Node, Vite y MySQL.

Aunque al inicio pueden aparecer algunos errores relacionados con PATH, Node, dependencias de npm o autenticación de MySQL, la mayoría tienen solución rápida si entendemos cómo está organizado el entorno.

Para desarrolladores que trabajan constantemente con Laravel, una combinación como Laravel Valet + Homebrew + nvm + MySQL puede convertirse en una base de trabajo muy sólida y profesional.

GitHub

Al crear el repositorio nosotros te recomendamos que lo dejes vacío ya que esto evitará que tengamos que hacer un commit extra al momento de sincronizar el proyecto.
Ignora estos documentos a menos que los necesites:

• Read me.
• Gitignore.
• Licence.

Inicializar proyecto

Desde la terminal (consola) ingresamos a nuestra carpeta.

cd /ruta/denuestra/carpeta

Una vez estando en nuestra carpeta ejecutamos los siguientes comandos:

1. git init
2. git add .
3. git commit -am “Inicialización del proyecto”

Una vez que ya tenemos inicializado nuestro proyecto procedemos a sincronizar la información, los siguientes comandos te los da el mismo GitHub al momento de crear el repositorio vacío.

git remote add origin git@github.com:tusuario/turepositorio.git
git branch -M main
git push -u origin main

Si todo ha ido bien ya podrás ver tu proyecto sincronizada con tu repositorio.

Si necesitas ayuda para crear un proyecto de software en Maria Tech contamos con los expertos para apoyarte.

logoutOtherDevices: Invalida la sesión del usuario en otro dispositivos, lo saca de la cuenta y solo mantiene la sesión actual del dispositivo que se está utilizando.

1- Integrar el middleware “auth.session” a la ruta o grupo de rutas donde se requiere tener acceso a la aplicación

Route::middleware(['auth','auth.session'])->group(function () {
//Aquí van todas tus rutas
}

2- Verificar que tenemos activo el middleware de “auth.session“
Para eso nos iremos a nuestro archivo “/app/http/kernel.php“, y asegurarnos que el arreglo “$middlewareAliases” tenga los valores:

protected $middlewareAliases = [
'auth.session' => \Illuminate\Session\Middleware\AuthenticateSession::class,
];

Nota: Debes tener más valores en el array, aquí solo te mostramos del que estamos hablando.

3- Agregar la función para ejecutar el proceso de cerrar las otras sesiones
Esto lo haremos en el controlador de autentificación “/app/Http/Controllers/Auth/AuthenticatedSessionContoller.php“,  agregamos la función “authenticated” (pueden usar otro nombre para la función)

/**
* authenticated Logout other devices
* @param string $current_password
*/
protected function authenticated($current_password) {
  Auth::logoutOtherDevices($current_password);
}

4- Incluir la llamada de la función cuando el usuario ya se autentificó en la aplicación

/**
* Handle an incoming authentication request.
*/
public function store(LoginRequest $request): RedirectResponse
{
  $request->authenticate();
  $request->session()->regenerate();
  $this->authenticated($request->password);
  return redirect()->intended(RouteServiceProvider::HOME);
}

5- Limpiamos la cache de las rutas para que nos detecte la aplicación las modificaciones

php artisan route:cache

Referencias

https://laravel.com/docs/10.x/authentication#invalidating-sessions-on-other-devices

https://laracasts.com/discuss/channels/laravel/logout-users-from-other-devices

Si te ayudó este contenido no olvides dejarnos tu comentario, bye.

PHPMailer es una librería basada en PHP que nos permite enviar y recibir correos usando el protocolo SMTP.
Para poder hacer uso de ella debemos integrarla a nuestros proyecto, aquí te dejamos el link para que veas cómo se hace y le des una leída a la documentación:

https://github.com/PHPMailer/PHPMailer

Antes de configurar nuestras credenciales debemos asegurarnos de dos cosas:
1- Tener activada la extensión openssl en nuestro servidor, si no la tenemos nos dirigimos al archivo de php.ini y descomentamos la línea

extension=php_openssl.dll

2- Activar el acceso a aplicaciones poco seguras de Gmail, te dejamos el link de cómo hacerlo:

https://support.google.com/a/answer/6260879

Una vez que tengamos incluido PHPMailer en nuestro proyecto, tengamos activa la extensión de openssl y activado el acceso a aplicaciones poco seguras de Gmail esta sería la configuración de las credenciales:

$config = array (
  'params' => 
  array (
    'mailer' => 'smtp',
    'secure' => 'ssl', 
    'host' => 'smtp.gmail.com',
    'port' => 465,
    'auth' => true,
    'user_name' => 'user_name@gmail.com',
    'password' => 'password',
    'from_name' => 'User Name',
    'debug' => 0
  )
);

Te recomiendo que leas la documentación de PHPMailer antes de comenzar a usarla para te sea más sencillo aplicarla en tu proyecto y recuerda que si te ayudó este contenido déjanos tu comentario, bye.

La librería la encuentras en Packgist bajo el nombre “luecano/numero-a-letras” aquí te dejamos el link:

https://packagist.org/packages/luecano/numero-a-letras

En este mis enlace te explica de una manera clara y precisa cómo agregarlo a tu proyecto y cómo usarlo.

De igual también lo encuentras en GitHub por si quisieras usarlo en otros proyectos que no fueron desarrollados con Laravel.

https://github.com/lecano/php-numero-a-letras.git

Aquí te dejamos un pequeño ejemplo para te des una idea como funciona

use NumeroALetras;
class NumeroALetrasController extends Controller {
 public function getNumeroALetra(float $numero) {
    $formatter = new NumeroALetras();
    $formatter->apocope = true;
    $formatter->conector = "pesos";
    $amount_text = ucfirst(Str::lower($formatter->toInvoice($numero, 2)));
    $amount_text .= "M.N.";
    return $amount_text;
    }
}

Suponiendo que el número que nosotros pasamos a la función es $58,518.72 el valor de retorno sería el siguiente: Cincuenta y ocho mil quinientos dieciocho pesos 72/100 M.N.

Lee la documentación para que puedas sacarle todo el proyecto a la librería.

Y recuerda que si te sirve este contenido no te olvides de dejarnos un comentario bye.