Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

nolros's avatar
Level 23

Stop adding poor quality Laravel addons

I've been a Laravel champion since the early days, but it is becoming more difficult. Stop adding crappy add-ons like Sanctum, Socialite, etc. as they are not production ready and require endless troubleshooting. Beyond basic vanilla installation or pure PHP, these products seldom work and god forbid you throw client side code into the mix. Every now and then I return to many of these products, like the infamous Socialite only to see that the product has made zero progress with the forums full of unanswered questions or on Github closed without a response as most of the issues are assessed to be "configuration" issues. Even Forge, which I really like, is a nightmare and you can spend days troubleshooting something as simple as env variable and seeding. A lesson in futility and assuming you have a week to waste --- try to build a SPA with Vuex, VueRouter and Sanctum / Socialite.

0 likes
41 replies
Ashraam's avatar

As a laravel champion you should help them to make those packages production ready then !

Snapey's avatar

Just remind me, those are FREE packages yes? Ones that you use for free to make a living?

Why not just write it all yourself.

11 likes
nolros's avatar
Level 23

Solid response @snapey ... the kind I would expect from my 10 year-old. Free doesn't have to be crappy. Lots of great software libraries that work that are "free" Just focus on the few that they do well. Don't add stuff that doesn't work or cannot be supported, as it will just end up in the decline of Laravel base. For example, how many people actually use Laravel Socialite for OAuth1 ... the amount of forum discussion from 2015 today with the same questions is mind boggling. In the end people will move to platforms with better support and products. Notice that Laravel doesn't rank in the top 10 dev platforms, alongside many other "free" platforms.

2 likes
Tray2's avatar

Since they are open source there is nothing preventing you from making them less "crappy". The thing about open source is that people build what they feel they need and just like a size 8 shoe it will not fit everyone. There is no need to create a bad mood on this forum just because you don't like an answer someone provides.

If it does not work for you then don't use it plain and simple. And if you don't like where Laravel is heading talk to Taylor about it since saying it's crappy here will not reach him or any of the other developers on the Laravel team.

7 likes
cmdobueno's avatar

Ummm i built a laravel sanctum spa with socialite, and I even had to deal with the frontend and backend being totally seperate... the tools work perfectly, pretty sure the issue is between the chair and keyboard...

12 likes
Snapey's avatar

I dont normally bitch, but a common complaint by open source developers is the criticism they get from people with an 'entitled' attitude. You just come across as one of those.

6 likes
jlrdw's avatar

I think he's just venting. He's knows all about open source. As a community, we also act as counsellors at times.

Part of supporting one another. Everyone at times gets frustrated.

3 likes
nolros's avatar
Level 23

@snapey first, I have nothing but respect for you and the moderators on this forum. You guys kill yourself and it greatly appreciated. You are always willing to help and answer questions, so this is not directed at any of you.

Just some developers become huge egos for reasons I don't understand. Not creating life, just software. Stay humble and be direct. There are many that take pride in what they develop and remain humble. I get it is open source and people take time out of their schedule to develop this stuff and again I'm grateful for the work and sacrifice that is made. Not complaining about any of them.

My issue is the endless hours to work, research and troubleshoot poorly developed and supported products Laravel and some of the addons are best-in-class.

My point is if you cannot support the product or unsure if it is production ready then just say so or do not publish. No heartburn, but when I spend days debugging code and questions are closed without any direction then I'm wasting my time and would have liked to know about the level of support and quality beforehand. Socialite, Sanctum and even Forge are painful. Great ideas, but painful as they seldom work as documented nor do they have effective support. Example, Socialite and OAuth1 is a nightmare, just say so. Sanctum sessions and cookie sync, also a nightmare. Fair enough a new product, but there are pages of issues and people are being directed to forums. Yes, maybe half are “configuration issues”, but the other half are legit and how would I know which as I didn't dev the product.

Graham and Dries close off github questions without even taking a look and the reason is they have 300 things on their plate. I get and empathize with their load, but my advice is do less - dont code things that are going to add to their plates or if you do then just say, this is an alpha or beta product and will only be supported in forums, that way I don't waste their and my time. Seems fair.

In contrast, the Spatie team products are rock solid and if they cannot support or don't think it is production ready they will say so. Example. Atom feed was not great and their response was to that effect. The Schema product they have killed themselves to support and develop. That said, when there are real issues they don't just close off and direct to forums. I cannot say enough good stuff about Sebastian De Deyne and Freek, in fact the entire team. So I take the time to help and research features, bugs, etc. because it it is a mutual exchange of value.

My point is just be direct and don't code it if it's going to create heartburn or add to the load. Let someone else do it. Also, be humble and dont shoot junior developers down when they asks questions, because we all asked questions along our journeys.

2 likes
Snapey's avatar

@nolros Thanks. A more considered response. You initial post was just ranty.

btw this forum does not have any mods (to my knowledge) other than Jeffrey

5 likes
nolros's avatar
Level 23

@cmdobueno " between the chair and keyboard" that is actually good .. lol ... on serious note, if you use pure PHP and OAuth2 driver then sure, but if you are using OAuth1, like Twitter, or 3rd party I very much doubt you have it working because the product is broken. Sanctum has session to cookie sync issues, but as it is new I understand. I posted this in 2015 https://github.com/laravel/framework/issues/8390 and needless to say the same issues still exist. Graham's response was to close it down without an answer for which he received 20ish thumbs down. So Ive attempted to help the process. I get email each month from people asking how I solved it. Nowadays the ServiceProvider is autoloader so you can't inject you own, capture the event or decorate. Even app()->(SP, null), wont kill it. It is ok as it is opensource, but people should be warned not to use the product, which was the purpose of this message.

willvincent's avatar

Looked at the issue.. appears that the most recent comments offer solution(s), and indicate "it should be added to the docs"

Great. add it to the effing docs then.

https://laravel.com/docs/7.x/contributions

Rather than bitching about "shit doesn't work" or "documentation is shit" ... submit fixes, and better documentation. That's literally the point of open source.

nolros's avatar
Level 23

To whom are your addressing your comment? Unsure of your point? What comments? If me then read the above as I have done that exact thing https://github.com/laravel/framework/issues/8390 only for it be closed without any response. If you go search twitter and OAuth1 issues then you will see most them are identical to the issue I raised as far back as 2015. The problems continue with autoloading, session management, SPs, etc. which I've submitted but they get closed off without a response and directed to forums. My point again, is that I get people are busy, no heartburn, but then just disclose that so we don't waste time.

nolros's avatar
Level 23

Thanks to all that replied. Agreed a little rant which started at 3AM after a day of debugging some of the Laravel code. I should have focused energy on blasting an ex girlfriend instead ... lol

Snapey's avatar

as I mentioned, there are no mods - only Jeffery

JvK-94's avatar

Hi, I'm new but why not think about a solution? Should there be a section on laracast with all the add-ons with the pro's and con's of them. Would be great if we help each other. Like many said, you can't restrict who is putting out there packages but some sort of validation couldn't be bad.

1 like
nolros's avatar
Level 23

@jvk-94 actually a great idea. There are some incredible add-ons.

btw, this a great source, but no real assessment of what is good or bad https://github.com/chiraggude/awesome-laravel

fwiw, off the top of my head i.e. what Ive used . Here is a start

Great Products & Great Support

  • davejamesmiller/laravel-breadcrumbs // excellent
  • wildbit/swiftmailer-postmark // excellent
  • timehunter/laravel-google-recaptcha-v3
  • intervention/image // excellent
  • ramsey/uuid
  • maatwebsite/excel // excellent
  • tymon/jwt-auth
  • spatie/schema-org // excellent
  • spatie/laravel-permission // excellent
  • spatie/laravel-tags
  • barryvdh/laravel-debugbar // excellent
  • laravel/framework
  • laravel/ui
  • Laravel Mix
  • Laravel Backup / Spatie
  • spatie/eloquent-sortable
  • algolia // excellent

Good Product & Ok Support

  • kalnoy/nestedset // it is complicated technology. I get teh sense author does have the time to enhance or fully support

Good Product & Poor Support /

  • laravel Forge // great product unless you run into issues. I once spent 5 days debugging a ENV / seeding issue ... zero documentation and the laravel team tends to close out everything
  • laravel Spark // another good product, but I had learned my lesson on other laravel products so as soon as I ran into issues and the same zero support then I bailed
  • Spatie Atom // they are upfront about the support of the product, which is great and in my opinion more than fair

Beta Product & Poor Support

  • laravel/sanctum // to be fair just released, but when Is see legit questions closed out without a response I would say stick with JWT or just know it not production ready. The cookie session thing is a pain, although there are workarounds.

Poor Product & Poor Support

  • laravel/socialite // avoid like the plague unless it is Facebook or Github - works ok for those two OAuth2 solutions. The latest problem is autoloading which makes it impossible to decorate. I posted a solution to teh Oauth problem in 2015 that persists today. I get emails monthly asking for help. No only is there no solution, but most github questions are closed out immediately.
1 like
siangboon's avatar

every expert was once a beginner...

every good product was a crappy product too... (i believed that most people start it with good intention but not many can maintain it well after a long period of time.... check back the old version of laracasts :p, now, it have became one of the main learning source and forum for every Laravel user...)

there are ton of app/games are crappy to me but not to others even some still ranked very high in the store... for example Pokemon Go is very good in design and the idea is good but the UX, features, implementation and logic of the app is bad for my experience, lot of crappy China RPG games are much better than it,

I believed that if it is really crappy it will just fade out from the market sooner or later, if not, meant there are still some people using it....

martinbean's avatar

@nolros Socialite and Sanctum work find if you use them properly and for their intended use cases 👍

shez1983's avatar

the only gripe i have is that the support you get from laravel team is pretty piss poor.. & very un-customer friendly (and i am talking about their paid products, forge/vapor)... at least they could say 'Hi... have you.. rather than a sentence.... which doesnt help

nolros's avatar
Level 23

@martinbean it is less a product issue than more of an author ego comment. Sanctum is new so to be fair it needs some runway. Whereas Socialite is social auth, doesn't get simpler and more specific than that ... setup the redirect, open a JS window, make a request which then provides a redirect to social provider and you have auth ... in theory. Unless you you have certain session or cors configurations or you using JWT or Sanctum, in which case OAuth1 issues or attempt to decorate to fix the issues. Again all ok as products have issues, but when people post the issues don't just close out without any feedback only to see people asking the same questions 4 years later with still no change to documentation or product. The onuses is on the Laravel community to let one another know this is not a solid product nor does it have the support. It happens anyway as people keep asking me if I found a solution to the problem I posted in 2015 and go read the problems on this forum alone?

Robstar's avatar

On Spatie, I agree with you there. I really like their support policy and how they respond to PRs/issues on Github. They have a great outlook on package development and always aim to keep packages focused on doing a specific task well.

gcavanunez's avatar

@nolros tymon/jwt-auth has so many issues. Not an expert might i add but everytime i've tried to get it to work just been a bit of nightmare in contrast to sanctum that though creates an additional database request, provides a simplier way to create stateless auth for spa's and mobile apps. Will add that I haven't used the session based approach to sanctum have just used the token approach.

irvv17's avatar

I'm starting a new project with Sanctum...

goppi's avatar

@nolros I actually share some of your frustration. I'm new to Laravel which certainly had an impact as well. That said, I am quite capable identifying issues due to learning curve vs issues due to poor documentation or poor support. To that end some of the "official packages" are in my view half-baked and to get them working made me think a few times if Laravel is really the right platform. The biggest issue I see with advertising those packages without any disclaimers as to their majurity throws a bad light on Laravel. I would love to see more transparency and in more detail.

I built an api app using passport and socialite for my own frontend. it's working and allows users to log in using email/password or various social network credentials. The problem i have is that if passport creates any exceptions and f.i. to validate if the user is logged in when calling a not restricted public endpoint, i can't prevent them from firing as the standard integration calls the oauth functions via the published routes. I found some articles how to make use of passport without using the routes, but it might just be easier to use sanctum and socialite. Could you share your thoughts on if Sanctum has been improved and is suitable in combination with Socialite for my needs?

Tippin's avatar

@goppi I will add that I personally use passport without using their published routes, however I only use the password grant / login / refresh capabilities. I found it was quite easy to wrap my own logic in my controllers and call to the base passport controller for authorization. I then can catch any errors myself and do things I want to happen, not what passport wants to happen. If you just need the simple login/refresh with passport, I can share how I did it myself.

goppi's avatar

@tippin Would be fantastic if you could share your code. Thank you

Tippin's avatar

@goppi Went ahead and removed some stuff that you will not need. Please note that the way I did this, I set my PASSPORT_PASSWORD_GRANT_CLIENT_ID and PASSPORT_PASSWORD_GRANT_CLIENT_SECRET in my env / passport.php config file, as I only require the secret to be posted (first party password grants like a mobile app). I merge the request with the ServerRequest interface and use the app container to create the passport controller and call its method. But feel free to checkout my API controllers and how I call passport behind the scenes. I'm sure there are better ways of doing this, but this is how I solved this issue 6 months ago and have not changed any code since then. (I did paste this into a fresh laravel 8 so tested nothing)

https://github.com/RTippin/laravel-api-auth

goppi's avatar

@tippin Thanks, I had a quick look and saw several reference to jwt, but very little to passport. How does jwt link into this, pls?

Tippin's avatar

@goppi The main part that calls the passport controller is this trait: https://github.com/RTippin/laravel-api-auth/blob/master/app/Http/Controllers/Auth/Concerns/HandlesApiAuth.php

I merge the base laravel http request from API with what passport expects "grant_type, scope etc". then I use the container to create the controller and ServerRequestInterface that passports method wants. Notice I am calling passports AccessTokenController

    /**
     * Request access token from oauth server
     *
     * @param Request $request
     * @return Response
     */
    protected function issueTokenFromServer(Request $request)
    {
        try
        {
            return $this->tokenServer()->issueToken($this->serverRequest());
        }
        catch (Exception $e)
        {
            $this->incrementAttempts($request);

            throw new HttpException(422, $e->getMessage());
        }
    }

    /**
     * Get the AccessTokenController instance
     *
     * @return Application|AccessTokenController|mixed
     */
    protected function tokenServer()
    {
        return app(AccessTokenController::class);
    }

    /**
     * Get the ServerRequestInterface instance
     *
     * @return Application|mixed|ServerRequestInterface
     */
    protected function serverRequest()
    {
        return app(ServerRequestInterface::class);
    }

The JWT part you see is not part of the login actually. You see no calls to it because I use it for events I emit. Basically that snippet lets me get the passport token ID out of the returned accessToken.

        $this->fireTokenDeviceEvent(
            $request,
            $this->guard()->user(),
            $this->parseJwtTokenId($this->jwt, $token)
        );

After login, in my app I fire this request so that a queued listener can do work on the database / link devices since I hand it directly the access token ID parsed using JWT, which is what passport uses behind the scenes to encode the accessToken. Usually when you login with passport, you do not have access to the oauth_access_token it created right away, thus using JWT you can get it back out from access token.

goppi's avatar

that's a neat bit of code i have to say. thanks for the explanation as well.

1 like
goppi's avatar

@tippin - it works very well. thanks again. there is just one problem i have I wanted to ask you about. I have an endpoint that doesn't require to be authenticated, however, if an authenticated user calls the endpoint (with the access token attached), I would like to record the user id. I have been using Auth::guard('api')->check() which correctly returns true or false, however if the user is not authenticated, OAuth2 is throwing an exception that the resource owner or authorization server denied the request. Ideally I would like to avoid that exception. I have another endpoint that I could call, but here as well, i would if not necessary avoid making an http call to myself. Do you know of any solution?

Tippin's avatar

@goppi Not sure if I fully understand you. Sounds like you want a single endpoint to work for guest AND auth:api. Only thing that seems confusing is you mentioned getting an OAUTH error, and not the typical "Unauthenticated" error. Either way, if you want a single route to work for both guest and auth:api, you can take my example where I made my own middleware, and all it does is do exactly what Authenticate middleware does, but catches the authorization exception and carries on.

AuthenticateOptional Middleware

<?php

namespace App\Http\Middleware;

use Closure;
use Illuminate\Auth\AuthenticationException;
use Illuminate\Auth\Middleware\Authenticate as Middleware;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;

class AuthenticateOptional extends Middleware
{
    /**
     * Handle an incoming request.
     *
     * @param Request $request
     * @param Closure $next
     * @param string[] ...$guards
     * @return mixed
     * @noinspection PhpMissingParamTypeInspection
     */
    public function handle($request, Closure $next, ...$guards)
    {
        try{
            $this->authenticate($request, $guards);
        }catch (AuthenticationException $e){
            //Not authenticated, continue on
        }

        return $next($request);
    }
}

Register in the kernal

Kernal

    /**
     * The application's route middleware.
     *
     * These middleware may be assigned to groups or used individually.
     *
     * @var array
     */
    protected $routeMiddleware = [
        'auth.optional' => AuthenticateOptional::class,
    ];

Use in your API route

Api route

Route::get('/api/endpoint', [SomeController::class, 'show'])->middleware('auth.optional:api');

Now guest or someone with a valid oauth token can hit the same route. Auth::check('api') or w.e will be true if they had a valid token, or just false if not authed, but no stopping via Authorization Exception

goppi's avatar

@tippin You understand me correctly and I do get an unauthorized reply back. At the same time however, Oauth is raising an exception which I can only see with Sentry. As I want to use Sentry or something similar in Prod, I would prefer not to get an exception. I'll try your code - perhaps it gets me around the exception in Sentry. Thanks again.

goppi's avatar

@tippin the $this->authenticate line in your middleware is still throwing the exception in Sentry. Perhaps the only way i get around this is by hooking into the OauthException handler and filtering unauthorized exceptions for those endpoints.

Tippin's avatar

@goppi Fair enough, do not use sentry myself. But I do also have the oauth server exceptions under my do not report in the Exceptions/Handler.php

<?php

namespace App\Exceptions;

use Laravel\Passport\Exceptions\OAuthServerException;

class Handler extends ExceptionHandler
{
    /**
     * A list of the exception types that should not be reported.
     *
     * @var array
     */
    protected $dontReport = [
        OAuthServerException::class,
        \League\OAuth2\Server\Exception\OAuthServerException::class,
    ];

goppi's avatar

@tippin I did something slightly different. I used your middleware as i need the user record anyway and in the exception/handler - report function I added this:

		if ($exception instanceof OAuthServerException &&
			$exception->getCode() == 9 && // The resource owner or authorization server denied
			Str::contains($exception->getTraceAsString(), 'app/Http/Middleware/AuthenticateOptional.php')) {
			return;
		}
Tippin's avatar

@goppi If it works, then yay! Hope you got what you needed working though.

Please or to participate in this conversation.