Why Sentry?

It`s simple - read the feature list https://cartalyst.com/manual/sentry#authentication

I did not ask for the features list. I have asked what are the features of it you leverage the most.

Honestly i've tried Sentry a couple of times and it's great, however i always seem to run into issues with it... there is always something i want to do that gets overly complicated because i'm using that package... So honestly i've dropped it and just went for the DIY route...

What have you wanted to do that got overly complicated to achieve with Sentry?

I like the atomic way you can set permissions in Sentry but I'm not so keen on the overuse of exceptions. Seems like your entire authentication and role/permission checking is a huge bundle of try/catch blocks

I'm with @pobble on this. to be honest the amount of exceptions that it can throw just puts me off completely.

Thanks for the feedback!

Do you have an alternative login/registration package that you're using?

Currently i just create it all from scratch but have been looking at : http://packalyst.com/packages/package/zizaco/confide and it's brother package : http://packalyst.com/packages/package/zizaco/entrust but haven't really looked into it yet

the worst thing about sentry is it throws exception in almost every case. why i need a damm exception when user gives a wrong password?

@Milon521 Agreed man! have you checked the amount of Exceptions it throws on Authentication Alone ?

I migrated an old app from native to Laravel when i first tried sentry and a simple thing like checking if the password a user entered is the same as a sha1 version of the password in DB if Authentication fails took so much more work because of all the exceptions, where laravel Auth::attempt() just returns NULL.

They tried to over complicate Sentry in my opinion however i do think it's not all bad, and some people may want all those exceptions ( i just don't ).

What have you guys gotten against exceptions? Why wouldn't it throw an exception when user provides wrong credentials? Your code might be cleaner because of this.

I am, on the other hand, having rough time with Sentry Throttling. What does it even mean? What is it used for?

@toniperic that is when a user tipes in his password wrong an X amount of times then he gets throttled ( aka suspended ) for X amount of minutes.

And It's not that we have something against exceptions. it's just you know when there is to many of them. and believe me there are too many.

If you're using an IDE like PhpStorm, the exceptions really aren't an issue. That said, I still don't like Sentry simple because it's too robust for my needs.

ask yourself is this :

try
{
    // Login credentials
    $credentials = array(
        'email'    => 'john.doe@example.com',
        'password' => 'password',
    );

    // Authenticate the user
    $user = Sentry::authenticate($credentials, false);
}
catch (Cartalyst\Sentry\Users\LoginRequiredException $e)
{
    echo 'Login field is required.';
}
catch (Cartalyst\Sentry\Users\PasswordRequiredException $e)
{
    echo 'Password field is required.';
}
catch (Cartalyst\Sentry\Users\WrongPasswordException $e)
{
    echo 'Wrong password, try again.';
}
catch (Cartalyst\Sentry\Users\UserNotFoundException $e)
{
    echo 'User was not found.';
}
catch (Cartalyst\Sentry\Users\UserNotActivatedException $e)
{
    echo 'User is not activated.';
}

// The following is only required if the throttling is enabled
catch (Cartalyst\Sentry\Throttling\UserSuspendedException $e)
{
    echo 'User is suspended.';
}
catch (Cartalyst\Sentry\Throttling\UserBannedException $e)
{
    echo 'User is banned.';
}

Realy necessary ?

And if you think that's all it throws for Auth think again, i cannot remember all the rest but one that was a serious pain in the behid was a Pasword Hash mismatch exception that also get's thrown... now in my opinion if the password doesn't match it doesn't right ? so why this extra exception ?

I agree, there might be too many of them but the way it handles permissions is so nice.

How do you handle permissions in case you need them?

@toniperic I wrote a package at the start of the year (when I was first getting into Laravel, so the code isn't great and it isn't tested). Github repo here.

Luckily, @foxted is fixing it up here.

I know this thread is a few months old but I'd still like to chime in.

I agree that the number of exceptions makes it a real pain at times but again, it gives you flexibility. If you need to check for a very specific scenario (user not found, user not activated), you can do so very easily and then catch any other exception with a regular catch(Exception $e) call.

I think that it may be a tad more complex than it needs to but I can't disagree with the fact that it makes it easier to handle Auth. That being said, the project I am currently working on does not require anything crazy with permissions and such so my auth requirements are quite low. Ergo, plain old Laravel Auth for the time being.

Catching a regular exception presents a problem though, because you're not just catching exceptions that Sentry is designed to throw, those are the only exceptions you should be TRYING to catch. Other exceptions, you want to bubble up and get handled by the application-level error handling.

This would be solved extremely easily if sentry just used an interface for their exceptions, like so:

class LoginRequiredException extends InvalidArgumentExceptions implements SentryException
{
//stuff
}

But as far as I know they don't.

According to a blog post by Martin Fowler, exceptions shouldn't be used for validation.

http://martinfowler.com/articles/replaceThrowWithNotification.html

@5pArxz in fairness to sentry they do that because in theory you should not edit source code, but rather decorate and as such create a ton of exceptions and events for you to tap into without the need to decorate. If you think they have a lot of exceptions go take a look at the events. Again overkill, but allows the average developer to tap into what they need . The joys of packaged apps / libs.

@nolros I've completely forgotten about this thread lol, i agree with you however i just like to handle stuff like authentication myself as most of the time system's i work on requires some unique way of authenticating ( not always ) and for me there is nothing wrong with Laravel Auth so i don't feel the need to use something like Sentry because at the end of the day it just creates more work for myself and why would i do that ? sure if i write a native app i would consider Sentry or Cofide etc.

I wouldn't go with Sentry as the latest version Senitinel is a paid product. I find rolling my own easier as well for most cases.

@polarcubs Thanks for that update, i didn't know that, now i will most definitely not be using it ever... lol :P

I would not say that the way it handles exceptions is the turn-off, my main trouble with it is that it is too slow . @thepsion5 made a great point with that wrapper, I think that goes right into the notification reply of @Ruffles.

I would not use Sentry because I am happy with laravel 5 Auth , but there are some legacy stuff on my back that need that wrapper.

@decebal2dac This thread is at least 8 months old ;)

I don't think you can compare Sentry and the build in Auth from 8 months ago ;) Yeah of course the build in Auth is really good now, but it wasn't there 8 months ago :P

For those of you who don't like Sentry, how do you feel about Laravel auth?

@csuarez Laravel Auth package is way better than Sentry and can be used as suggested in this thread. Do you happen to know something that can help me easily switch from Sentry to this on a legacy project ? I was thinking of designing a small service provider, bind it to my ioc container and when all the legacy stuff is migrated to this just switch off Sentry and replace it with Auth in the bindings file. Hope it makes sense.

yup thanks @decebal2dac