Notable Changes

Sentry 2 is a full rewrite of the Sentry library. A new API, new methods, with
some database changes (no more user metadata table) and the use of Eloquent for
our models.

With this rewrite we felt we should note some key changes that may cause issues
if you are porting from the original Sentry library.

Dependency Injection / Interfaces / PSR

We made Sentry2 to be PSR-0, PSR-1 and (mostly) PSR-2 compatible and take
advantage of Dependency Injection. We feel this will allow more people to use
Sentry to fit their needs. Because we have opted to use Dependency Injection,
we have provided several interfaces to keep the Sentry API as consistent as
possible for your application. We hope this serves you well and allows you to
easily switch out classes for your own needs without having to modify your
application in the future.

Exceptions

Since we are making Sentry 2 composer-based and framework agnostic, we wanted to
limit dependencies were we could. As a result, we made more descriptive
Exceptions which should allow you to catch and make your own error messages for
them. There is no longer a SentryException catch all.

Sentry::login() and Sentry::force_login()

Sentry::login() used to take 2 required parameters, login and password, and
authenticate the user against them. Sentry::login() is now used as a login for
both authentication and force login, used by passing a UserInterface object.

A new Sentry::authenticate() method has been introduced for authentication
purposes and should replace your Sentry::login() methods. This method passes
an array which requires just the login (email) field by default to authenticate
against. You may also choose any number of fields you may also want to validate
against, such as password, first name, or any other field you may add to your
users table. We always recommend using a password, but you may have your own
ideas for which you want to authenticate against instead.

Sentry::user()

Sentry::user() used to return the active user, if they existed, or the user
requested by passing in an optional parameter of their id or login field. To get
the active user, you now use Sentry::getUser() . This will check if their is
an active user and return their object, otherwise it will return null.

To find specific users, you can retrieve a User Provider by calling
Sentry::getUserProvider() and taking advantage of 3 new methods, findById(),
findByLogin() and findByCredentials() .

Objects over Arrays

By high demand, we now use objects over arrays for pretty much everything in
Sentry 2.

User Metadata

We used to have a separate table and array key for user metadata. This table has
been completely removed, along with the metadata key. If you wish to have user
metadata, simply add the columns onto the current users table.

Password Reset

Many people were initially confused as to why we would prompt for a password
during the initial password reset request. In Sentry 2 we have decided to go
back to the more ‘normal’ approach and ask for the new password after receiving
the confirmation code.

Password Hashing

Sentry2 now uses BCrypt by default as it’s password hashing algorithm. We still
have a SHA-256 Hashing driver included in the library you can easily switch to
if you wish to still use our old hashing algorithm.

Sentry::group()

Sentry::group() changes pretty much reflect the Sentry::user() changes.
This method no longer takes any parameters and returns an empty Group Provider
Object. You can find specific groups by using the findById() and findByName()
methods.

Session/Cookie

We used to only store the current user’s ID in the session, we now store the
UserInterface object.

Throttling

Throttling has had some minor changes, but all in all works pretty much the
same. One new key feature is we now allow banning of users.