Mongodb Sentry Laravel Package

Getting Started

Step 0 — confirm you are in the right place. This package is not getsentry/sentry-laravel error monitoring. It is a MongoDB user provider for Cartalyst Sentry (the abandoned auth package, later replaced by Sentinel). If you want users/groups/permissions in Mongo and you already use jenssegers/mongodb + Cartalyst Sentry, you are in the right place. Otherwise, stop and use native Laravel auth.

Install

composer require jenssegers/mongodb-sentry

Because v1.1.0-beta depends on a Sentry feature branch, you will likely need to allow dev stability for this package only — prefer "jenssegers/mongodb-sentry": "1.1.0-beta as 1.1.0" or a commit-pinned dev- reference over flipping root minimum-stability: dev.

Where to look first

1. composer.json — note which Sentry branch/tag it pins. This is the single biggest risk.
2. The package's user provider class (extends Sentry's Eloquent provider but points at a Mongo Eloquent model).
3. Its default config (model class + collection/connection names).
4. Cartalyst Sentry's own config (app/config/packages/cartalyst/sentry/config.php) — this is where the provider class is swapped.

Register

• Add the package's service provider in config/app.php (Laravel 5 style) if it is not auto-discovered.
• Publish/merge the package config to set your connection and collection names.
• In Sentry's config, set 'users' => ['model' => YourMongoUserModel::class] and ensure Sentry's SentryUserProvider points at the Mongo implementation.

First use case that proves it works

Sentry::register([
    'email'    => '[email protected]',
    'password' => 'secret',
]);
$user = Sentry::authenticate(['email' => '[email protected]', 'password' => 'secret']);
Sentry::login($user, false);          // session persistence
Sentry::getUser()->hasPermission('admin');

Then check MongoDB: db.users.findOne({email: '[email protected]'}) — the document (not a row) confirms the provider is wired. Group and permission check via hasAccess()/hasPermission() closes the loop.

Implementation Patterns

Custom model extending the Mongo base. The package supplies a base model; create your own so you can add app fields without touching vendor code:

use Jenssegers\Mongodb\Eloquent\Model; // or the package's provided base

class User extends \Jenssegers\MongodbSentry\Models\User
{
    protected $collection = 'users';

    // add app-specific fields/accessors here
}

Then point Sentry's config at User::class.

Config-driven collection/connection switching. Keep collection names in config, not hardcoded, so you can use an isolated sentry connection:

'users'  => ['model' => App\Models\User::class, 'collection' => 'users'],
'groups' => ['model' => App\Models\Group::class, 'collection' => 'groups'],

This is what makes it usable day-to-day: you can point the collection at a dedicated Mongo database or the app's existing one without code changes.

Multi-tenant / multi-database. Because the model uses a Mongo connection, per-tenant switching is done by swapping the connection (or collection prefix) at runtime before the Sentry call. Keep this in a middleware or service provider that runs before auth resolves the user — otherwise Sentry caches the model instance from the wrong database.

Groups and permissions. Use Sentry's API as normal, but be aware the nested structures (groups → permissions) become subdocuments in Mongo. Common pattern:

$group = Sentry::findGroupByName('admins');
$group->permissions = ['admin' => 1];
$group->save();

$user = Sentry::findUserByLogin('[email protected]');
$user->addGroup($group);

Queries like Sentry::findAllUsersWithAccess('admin') translate to Mongo queries on nested subdocs — verify the index exists (see below).

Testing. Point the test suite at a throwaway Mongo database via the connection config and flush between tests. A focused smoke suite that covers register → authenticate → group membership → permission denial is worth more than full coverage here, because the failure modes are auth failures, not logic bugs.

Wrapping login attempts. Sentry records attempts in a Mongo collection; if you need throttle/audit dashboards, read from there — it's just documents. This is a genuine day-to-day win over SQL.

Gotchas and Tips

The name collision will cost you time. Stakeholders, issue trackers, and even onboarding engineers will assume this is error tracking. Put a one-line comment in composer.json or a README note in your app. Every roadmap conversation needs this framing up front.

Beta + feature branch = non-reproducible installs. v1.1.0-beta pins to a Sentry feature branch you do not control. Commit composer.lock, and prefer commit-pinning the branch (#<sha>) over a floating dev-master. If upstream deletes the branch, fresh installs break silently while your locked builds keep working — so reinstall from scratch in CI occasionally to catch drift before a deploy does.

Fail-closed is not guaranteed. If Mongo is down, the collection is renamed, or the config points at the wrong connection, provider resolution can throw or return null. Wrap in a way that treats "no user" as unauthenticated, and write a test that simulates a missing collection. An auth provider that silently resolves to a different user is worse than a 500.

Index the hot path. Auth runs on every request. Ensure indexes on email, login, and any group-name/access query path (db.users.createIndex({email: 1}, {unique: true})). Without a unique index on email you can end up with duplicate logins — Sentry's relational provider assumed the DB would enforce that; Mongo will not by default.

Noisy neighbor in a shared Mongo. If Sentry shares a cluster with app data, a permission-heavy query or a collection scan can degrade login latency for the whole app. Separate connection (even if same cluster) and watch connection pool size.

Config drift after upgrades. After any jenssegers/mongodb or Laravel bump, re-run the auth smoke test. Field name mappings and $dates/casts on the Mongo model are the usual breakpoints — a login still works while last_login or remember_token silently stops persisting.

Extend, don't fork. Add app fields via a subclass and accessors; the vendor code is thin and you may need to patch it when upstream dies, so keep your diff small. Keep a document of exactly what you override — future-you will need it to fork.

Have an exit ramp documented. Because Sentry is deprecated and this package is beta, keep an export script that dumps users/groups collections to a neutral format (JSON/CSV) so a migration to native Laravel auth or Sentinel is a data move, not an archaeology project. This single artifact de-risks the whole dependency.