Skip to content

Latest commit

 

History

History
93 lines (60 loc) · 5.13 KB

File metadata and controls

93 lines (60 loc) · 5.13 KB

Changelog

0.10.0 (2026-09-08)

BREAKING — the page snippet is now required

A page response no longer sets the visitor cookie. Only POST /_mbuzz/session mints, and the inline snippet in the README's "Full-page caching" section is what calls it. Upgrading without adding that snippet stops tracking entirely — no cookie is ever minted, so no visitor exists and every event is dropped.

The reason: a page response can be stored by a full-page cache and replayed to every visitor. A Set-Cookie sitting in that cache hands everyone the first visitor's id, merging unrelated people into a single journey — corruption rather than loss, since every row still exists and is simply attributed to the wrong person. Nothing looks missing, which is what makes it dangerous.

Verified against nginx proxy_cache in sdk_integration_tests/scenarios/page_cache_test.rb: before this change three visitors on a cached page received one id; after it, three. The WordPress plugin reached the same conclusion first (CookieBootstrap::CONTEXT_PAGE).

Fixed

  • Attribution behind a full-page cache. A cached page is served without entering the application, so the middleware never ran, no visitor cookie was minted, and every later event and conversion was dropped for having no visitor — silently, with no HTTP call and nothing logged. The middleware now answers POST /_mbuzz/session, a path caches don't store, and the server sets the cookie on that response. The id is never created or read in JavaScript, so it stays HttpOnly and keeps its full two-year life. Add the inline snippet from the README's "Full-page caching" section to your base template.

  • A dropped call now says why. event() and conversion() returned failure with no request and no log when no visitor_id and no user_id could be resolved — a dropped conversion and a delivered one looked identical from the caller's side. Both now log a warning naming the call, the reason, and the fix. Not behind the debug flag: the customers who hit this are the ones not running in debug.

  • __version__ said 0.8.2 while the package was 0.8.3. Both now track the release.

Added

  • Django middleware (mbuzz.middleware.django.MbuzzMiddleware) and FastAPI/Starlette middleware (mbuzz.middleware.fastapi.MbuzzMiddleware). Both frameworks were advertised in the package metadata but only Flask middleware shipped, so those users got no cookie minting at all — a 100% silent-drop path unrelated to caching. Each includes the session endpoint above.

  • The django and flask extras now actually declare their framework, instead of being empty.

0.8.3 (2026-05-25)

Deprecated

  • identifier parameter on conversion(). Pass the email or external ID as user_id instead. The backend /conversions endpoint has never permitted this field — Rails strong params strip it — and the events endpoint treats identifier.email exactly as user_id. The param still serializes into the payload (backwards-compatible — existing callers keep working) but now emits a DeprecationWarning once per process. Will be removed in a future major release. Matched by deprecation in mbuzz-php 1.2.1 and mbuzz-node.

0.8.2 (2026-03-15)

Changed

  • Removed api_url from init() parameters — the proxy URL (https://api.mbuzz.co/api/v1) is now hardcoded. This prevents accidental bypass of the edge ingest proxy. For development, config.api_url can still be set directly after init.

Fixed

  • event() and conversion() now handle proxy-buffered responses gracefully — when the edge proxy accepts a request but Rails is temporarily unreachable, the SDK returns TrackResult(success=True) with nil IDs instead of TrackResult(success=False).

0.8.0 (2026-03-13)

Changed

  • Default API URL updated to https://api.mbuzz.co/api/v1 — traffic now routes through the edge ingest proxy for improved reliability.

0.7.4 (2026-02-17)

Fixed

  • identify() now writes user_id back to context — after a successful API call, user_id is stored in the RequestContext so that subsequent conversion() calls in the same request can resolve it.

0.7.3 (2026-02-03)

Added

  • Navigation-aware session creation — middleware now only creates server-side sessions for real page navigations, filtering out Turbo frames, htmx partials, fetch/XHR, prefetch, and other sub-requests. Uses browser-enforced Sec-Fetch-* headers as the primary signal with a framework-specific blacklist fallback for old browsers.
  • device_fingerprint() utility — computes SHA256(ip|user_agent)[0:32], matching the server-side fingerprint for session deduplication.
  • Async session creation via POST /sessions — fire-and-forget background thread on real navigations.

Fixed

  • 5x visit count inflation caused by concurrent sub-requests (Turbo frames, htmx) each creating separate sessions on first page load.

0.7.0 (2026-01-15)

  • Initial release with Flask middleware, visitor cookie management, event tracking, user identification, and conversion tracking.
  • Session cookie removed — server handles session resolution via device fingerprint.