- What does winter-bridge/bridge actually do?
- It is a thin integration layer that extends Laravel's authentication stack so a Laravel application can resolve user identities against a Winter CMS instance. It plugs into Laravel's Auth guard and provider contracts and points user resolution at Winter's backend user model and related plugins such as RainLab.User. It is not a general-purpose auth package and adds no value to a Laravel-only stack. It only makes sense when you run both a Laravel app and Winter CMS and must share a single identity source.
- How do I install winter-bridge/bridge in a Laravel application?
- Installation is standard Composer: run composer require winter-bridge/bridge, then register the package's service provider and wire a custom guard and provider in config/auth.php. The package surface area is small, which keeps the integration tractable. Be aware the repository ships with minimal public documentation, so expect to read the source rather than follow a step-by-step guide.
- Which Laravel, Winter CMS, and PHP versions are supported?
- The package's last release was 2022-01-09, and compatibility with Laravel 9, 10, or 11 and current Winter CMS releases is unverified. PHP 8.2 and newer typing changes to Laravel's auth and session internals have not been validated against it. Pin exact versions of Laravel, Winter CMS, and PHP in composer.json, and run a compatibility matrix against your current LTS plus the next minor before committing.
- How do I configure the Winter auth guard in config/auth.php?
- You define a custom guard and user provider in config/auth.php that delegates user resolution to the bridge, which in turn reads from Winter's backend user model. The exact class names and driver keys should be taken from the package source since public documentation is sparse. Recommended sequencing is to vendor or fork the package first, then replace its shipped config with your own guard and provider definitions. Add integration tests around login, logout, session persistence, and password reset immediately after wiring.
- How does it share user identities between Laravel and Winter CMS?
- The bridge presumes a shared-database, single-sign-on model across both applications, with identity resolved against Winter's backend user records. It does not perform token exchange or OAuth; it works at the guard and provider level inside Laravel. The cookie and domain model between the two apps is the area where most integration bugs hide, so validate session semantics explicitly in staging. If you can centralize identity instead, a proper IdP path is preferable to a shared-schema bridge.
- Does it work with RainLab.User and Winter's password hashing?
- The package targets Winter's backend user model and related plugins such as RainLab.User, so user resolution follows Winter's records. Whether it fully preserves Winter's password hashing and user lifecycle events, or requires dual-writes, is not documented and should be verified in a spike. Confirm this before promoting to production, since any divergence in hashing or lifecycle events is a security-relevant defect.
- Is winter-bridge/bridge actively maintained?
- No. The last release was 2022-01-09, the project has a single maintainer (Teranode), about 7 stars, and 0 dependents. That means effectively no community regression testing and no downstream validation of the auth path. Treat the package as a starting point you fork and own rather than a dependency you rely on for upstream fixes.
- Is it safe to use in production for authentication?
- Authentication is a tier-0 surface, and an unmaintained package in the auth path is a standing risk with no CVE response and no patches. The realistic posture is to vendor or fork the package into your own organization, validate it against your pinned Laravel and Winter versions, and add a security review of the auth path. Roll it out behind a feature flag and budget for a quarterly compatibility review, because version drift is guaranteed.
- How should I test the bridge before deploying?
- Start with a time-boxed two-to-three day spike against your exact Laravel, Winter CMS, and PHP versions in a staging environment. Then add integration tests covering login, logout, session persistence across both apps, and password reset. Run a compatibility matrix in CI and follow the sequence: identity spike, fork or vendor, guard and provider wiring, session and cookie validation, security review, staged rollout. Do not interleave this work with unrelated large changes.
- What are the alternatives to using this bridge?
- If you can centralize identity, make Laravel the identity provider and treat Winter CMS as a relying party via OAuth2, OIDC, or SAML, or use laravel/socialite with a standard provider. That approach removes the dependency on an unmaintained package entirely. The bridge is the right tool only when a shared-database single-sign-on model across both apps is a hard requirement and a full IdP migration is out of scope.