- How do I quickly add Google OAuth login to my Laravel app using Bartender?
- Install the package via Composer, publish its migrations, and register the routes with `Bartender::routes()`. Configure Google as a Socialite provider in `config/services.php`, then run `php artisan migrate`. The package handles the `/auth/google/redirect` and `/auth/google/callback` endpoints automatically.
- Can Bartender work with Laravel 12 or 13?
- Yes, Bartender explicitly supports Laravel 12 and 13 alongside Laravel 9+. The package is tested against these versions and follows Laravel’s latest conventions. Check the [GitHub releases](https://github.com/DirectoryTree/Bartender/releases) for version-specific notes.
- What happens if I don’t need to store access/refresh tokens?
- You can skip the token-related migrations entirely. Bartender publishes optional migrations for `provider_access_token` and `provider_refresh_token` columns, but they’re not required. Simply delete the `2024_10_27_131354_add_provider_token_columns_to_users_table.php` migration file before running `php artisan migrate`.
- How do I customize user creation logic when a provider logs in for the first time?
- Extend the `ProviderHandler` interface or override the default `ProviderHandler` implementation. Inject your custom handler into the service container via `AppServiceProvider`’s `register` method. This allows you to define how user data maps to your model, handle duplicate accounts, or trigger custom events.
- Does Bartender support soft deletes for OAuth users?
- Yes, Bartender includes built-in support for soft deletes. If your `User` model uses Laravel’s `SoftDeletes` trait, the package will automatically respect soft delete behavior when associating users with OAuth providers. No additional configuration is needed.
- How do I add email verification for users logging in via OAuth?
- Bartender integrates seamlessly with Laravel’s built-in email verification. If your app uses `MustVerifyEmail`, users will receive verification emails after their first OAuth login. The package handles this flow automatically—no extra setup is required beyond your existing email verification configuration.
- What if I need to use a custom Socialite provider not supported by default?
- Bartender is designed for extensibility. You can create a custom `ProviderRepository` implementation to handle unsupported providers. Override the `getProvider()` method in your repository to return a configured Socialite provider instance, then bind it to the container in your `AppServiceProvider`.
- Are there any security risks with storing provider tokens in the database?
- Bartender encrypts token fields by default using Laravel’s `$casts` property. However, you must ensure the `provider_access_token` and `provider_refresh_token` columns are hidden in your `User` model’s `$hidden` array. Follow the README’s security guidelines to avoid exposing tokens in API responses or logs.
- How do I test Bartender’s OAuth flows in a CI/CD pipeline?
- Use Laravel’s `SocialiteTesting` facade to mock provider responses in tests. Bartender integrates with this facade, so you can simulate OAuth callbacks without hitting real provider APIs. Example: `SocialiteTesting::fake(GoogleProvider::class, ['user' => [...]])`. Test both success and failure scenarios for edge cases.
- What are the alternatives to Bartender for Laravel OAuth auth?
- Alternatives include Laravel Socialite standalone (more manual setup), `spatie/laravel-socialite-oauth` (simpler but less opinionated), or `laravel/breeze`/`laravel/jetstream` (which include basic OAuth but lack deep customization). Bartender stands out by combining Socialite’s power with ready-made routes, migrations, and a focus on extensibility for complex auth flows.